The owner of an accounting practice in Milan, eight collaborators, three hundred and fifty active clients, describes a recent decision this way: "we spent thirty thousand euros in six months to migrate the management system, install a CRM on top, and integrate the two. We thought this would be the one. Six months later the new set-up is operational, everyone complains that the CRM is not updated, and my personal time on client communications has dropped by maybe an hour a week. Not five, as we thought".
This experience is not an exception. It is the predictable result of a choice that, however reasonable, skips a step. Before understanding which step, it is worth looking at the three layers of software that coexist in a modern accounting practice and understanding what each does.
The first layer: the administrative management system
The classic management systems (TeamSystem, Datev, Zucchetti, Osra, Profis) are recording systems. Their job is to keep account of what has already happened and produce the filings required by law. Bookkeeping, financial statements, returns, payslips, withholdings, electronic invoicing. A management system does these things well, or badly. A good management system does them very well.
What a management system does not do, by construction, is help the practice decide what to do next. The management system does not propose, does not suggest, does not interpret. It records. Its implicit question is "what happened?", not "what do I do now?".
This is not a defect. It is the very definition of the product. A management system that tried to make decisions for the practice would become a different object, more fragile and less reliable in its primary job. You need to have a good management system, but recognise that it is a backbone, not a head.
The second layer: the CRM
The CRM (HubSpot, Pipedrive, Zoho, or Italian vertical solutions such as BrickUp or TopSmile) is a contact system. Its job is to keep track of the people the practice interacts with. Who has contacted whom, when, where the relationship stands, what has been promised, when to call back.
A CRM does this work well when it is updated. The structural problem of the CRM is that it depends on manual updating by people. When a collaborator talks to a client on the phone, the CRM does not know what was said unless someone writes a note. In practice, time to write the note is always short, the habit is uneven, and after six months the CRM is half full, with information of varying reliability depending on who entered what.
The CRM-management system integration that many practices implement transfers structured data (records, deadlines, contractual states) between the two systems, but does not solve the qualitative update problem. The CRM stays updated only where human beings update it.
Here too, it is not a product defect; it is the product's job. The CRM is designed to be fed by operators. If operators do not feed it, the CRM does not work.
The third layer: the cognitive layer
The third layer is what is missing. It does not yet have a consolidated name in the Italian market. We call it the cognitive layer for want of something better. Its job is to know the practice and make this knowledge available in an operational way.
Knowing the practice means having a structured corpus of information that goes beyond the structured data of the management system and beyond the isolated notes of the CRM. It includes the practice's communication style, the client behaviour patterns observed over time, the internal procedures, the exceptions applied to certain categories, the preferences of individual collaborators on how to handle certain situations.
Making it available operationally means that this knowledge is queryable by people and systems. A new collaborator can ask a question like "how do we usually handle extension requests from commerce clients?" and receive an answer reflecting the practice's way. An automatic email sorting system can decide to whom to assign a request using the implicit rules of the practice, not only a standard category classification.
This layer does not replace the management system. It does not replace the CRM. It rests on both and adds what neither contains: the business knowledge.
This is the error the Milan owner cites at the opening. Integrating the management system with the CRM does not produce the cognitive layer. It produces two archives that communicate better with each other. Both remain recording systems relative to their domain. Neither brings decision.
The reason is that business knowledge does not live in either before integration, and integration does not create it from nothing. Business knowledge must be made explicit, structured and made available in a format that tools can consume. This work is not software integration; it is knowledge work.
The Milan owner expected that migrating the management system and adding a CRM would "magically" shorten his time handling communications. It could not happen, because the time spent handling communications depends on knowledge that had not been structured. The new management system is nicer, the CRM well installed, but the time the owner spends deciding how to reply to client Rossi, client Bianchi and client Verdi is still his time, because the knowledge of how to reply to Rossi, Bianchi and Verdi is still only in his head.
What should have been done first
The correct sequence, seen retrospectively, would have been different. Not "first the management system then the CRM then the integration", but "first the map of the practice's knowledge, then the structuring of the part that really matters, then the choice of tools resting on the structure".
The knowledge map starts from a concrete question: where does the information needed to make decisions in daily work live today? Almost always, for an accounting practice, the answer is a mix: part in the management system (deadlines, fiscal data), part in archived emails, part in the invoicing system, part in the collaborators' personal inboxes, part in their heads, part in Excel files nobody really shares.
The structuring decides which pieces of this map should be systematised. Not all of them. You structure what has impact: the client categories requiring different treatment, the practice's communication style, the procedures for recurring queries, the internal escalation rules.
Only afterwards do you choose tools. A management system resting on a structured cognitive layer is used differently. A CRM receiving contextual notes on conversations from an automatic system stays updated. An email sorting system that knows the practice sorts according to real rules, not standard categories.
The cost of doing it in the wrong order
The cost of having done the tool integration first and then realising something else was needed is almost always higher than the correct path. There is a structural reason and a psychological one. The structural one: working on top of an already chosen infrastructure means making compromises on the right decisions, because some of those decisions are already taken and changing them would cost as much as starting over. The psychological one: after spending thirty thousand euros, no owner easily accepts hearing that the real problem was something else. Inertia leads to continuing with the same logic, refining it rather than rethinking it. Both reasons favour the correct path, when you start from the diagnosis before the tools. The Milan owner spent thirty thousand euros in six months. Of that sum, about a third was for the new software, two thirds for configuration, data migration and training. If after the thirty thousand euros the practice still does not have the cognitive layer, and decides to build it, the additional cost is not marginal: it must be done on top of an already chosen infrastructure, with constraints deriving from that choice.
Done in the right order, the path on average costs less, and gives results more consistent with expectations. The cognitive layer informs the choice of tools; the tools become executors of already structured knowledge, instead of hindrances trying to compensate for its absence.
How to tell where you are
A practical test: take a collaborator who has been at the practice for more than three years and one who has been there for less than six months. Ask both to reply to the same client email, without helping each other. Compare the two replies. If they are very different in tone, content, treatment of the client, you are seeing the symptom of a missing cognitive layer: the practice's knowledge lives in the seniors, not in the practice.
If instead the two replies are reasonably similar, without anyone having told the junior what to write, it means something of that knowledge has already been transmitted in a structured, even if informal, way. A good starting point to build more.
This exercise takes half an hour and produces a clear diagnosis. From there, deciding whether to invest first in tools or in structuring becomes much clearer.
If you recognise something of your story in the Milan owner, or even just the suspicion of being about to take the same path, it is worth a diagnosis conversation before any purchase decision. Forty-five minutes, a document that is yours at the end, zero commitments on what you decide to do afterwards.