Why law and accounting firm CRMs fail, and what replaces the data entry

Ask a marketing director at a law or accounting firm about their CRM and you will get a familiar answer, delivered with the resignation of someone who has had this conversation many times. The data is patchy. The partners do not use it. There is a plan to relaunch it.

The plan will not work, and it is worth being precise about why, because the reason is not the one usually given.

The reason it is not

The standard diagnosis is cultural. Partners are resistant to change. Leadership does not model the behaviour. There was insufficient training. The vendor literature says this too: low adoption, inconsistent data entry, unclear ownership, and the observation that if the managing partner is not using the system it stays optional for everyone else.

All of that is accurate as description. It is not a cause. It is the visible result of an economic calculation that every fee earner makes correctly.

The reason it is

A CRM asks a fee earner to spend time recording things. That time is not chargeable. In a firm, non chargeable time is the thing you are asked to justify at appraisal and the thing you defend by minimising.

So the request is: convert an hour you are measured on into an hour you are not, in exchange for a benefit that accrues to someone else, later, possibly. Stated that plainly, the response is obvious. It is not resistance to change. It is a competent professional responding rationally to how their firm measures them.

A senior partner declining to update a CRM is not being difficult. They are doing the arithmetic their firm taught them.

This has a consequence that most adoption programmes never confront directly. Data entry effort is inversely correlated with the value of the relationship. The partner with the deepest client relationships is the busiest, so their records are the thinnest. The system is emptiest exactly where it would be worth the most.

You cannot fix that with training, because training does not change the arithmetic. You cannot fix it with mandate, because mandates in partnerships have a short half-life and produce compliance behaviour rather than data, which is worse: a field filled in to clear a warning is a fact that is not true.

The three other structural problems

Even if adoption were solved, three design mismatches would remain.

A CRM models a pipeline, not a relationship. It is built around opportunities with stages and values, and contacts exist as attributes of those opportunities. Firms invert that: the relationship lasts decades, the engagements are episodes inside it. A structure where the contact hangs off the deal cannot represent a relationship that outlives every deal it has ever been attached to.

It records contacts, not capability. Even a perfectly maintained CRM answers who knows whom. It has no view of what the firm has proven it can do, which means it can never answer whether the firm has done something before, and can never show the gap between a client's needs and the firm's delivered work. That is two of the three questions firms actually have.

It is one silo among several. The CRM holds contacts, the practice management system holds matters, the document store holds deliverables, the finance system holds what was billed. Each is internally coherent, none connects to the others, and every question worth asking crosses at least two boundaries. Adding a CRM to a fragmented stack, as the accounting firm literature puts it, produces one more silo and doubles the entry burden.

What replacing the data entry actually requires

If the diagnosis is that manual entry is economically unsustainable, then the specification is not "a better CRM". It is a system with a different cost structure. Three properties follow.

Capture must cost close to nothing at the point of work. Not "quick to fill in". Nothing to fill in. The only inputs that survive contact with a billable culture are the ones that are already part of doing the work.

The unit has to be the relationship and the capability, not the deal. Which means the underlying structure is a set of people, engagements and proven capabilities linked to each other, rather than a pipeline with contacts attached.

Every fact must carry its source. Automatic extraction without provenance is worse than manual entry, not better. Manual entry at least has a human being who can be asked. An inferred fact with nothing behind it cannot be checked, and the first time one turns out to be wrong the system's credibility is gone.

How OrgAtlas approaches it

The design constraint was the arithmetic above: any capture step that competes with billable time will lose, so there must not be one.

Each account gets its own address. The team uses it the way they already use email. They blind copy it on the way out, forward a thread that already happened, or upload proposals, reports and notes in the browser. There is nothing to install, no mailbox to hand over, and no third party system to connect. Every input is a deliberate act by someone in the firm, which also means nothing enters the record that somebody did not choose to send.

From that material the atlas extracts the people, stakeholders, engagements and capabilities on the account and links them, and ties every fact back to the document or thread it came from. What the account team sees is a map of the account rather than a set of records to maintain.

Two things follow that a CRM cannot do. Capability is present alongside relationships, so "have we done this before" becomes answerable. And where the firm has no experience in something, the atlas says so, drawn as a gap rather than left out, so the space between what a client needs and what you have sold them is visible.

The test is simple. If a busy partner has to do something for the record to stay true, the record will not stay true.

What to ask a vendor

If you are evaluating anything in this space, four questions separate the categories quickly.

1. What does a fee earner have to do for this to stay current? If the honest answer involves them entering anything, the adoption curve will look like your last one.
2. Can it tell me what the firm has delivered, or only who has been in contact? This distinguishes relationship intelligence from a capability record.
3. When it asserts something, can I see the document behind it in one click? Without this, the first wrong answer ends the deployment.
4. What does it do when the firm has no experience of something? A system that always produces an answer cannot be trusted on the ones you cannot verify.

None of those are trick questions, and the answers are usually given plainly. They separate tools that changed the cost structure from tools that moved the same burden somewhere else.

Next: why email, not the document store, is the firm's richest record of what actually happened