Blog / Data foundation

Your CRM is not the problem. The missing semantic layer is.

Data foundation30 April 2026· 10 min
field notes

Replacing the CRM almost never fixes what people blame the CRM for. The missing piece is a layer above it that knows what an account is across every system, and what happened to it in order.

Every few years a revenue organisation concludes that its CRM is the problem, and proposes a migration. Eighteen months and a great deal of money later, the same complaints reappear in a different interface: the data is unreliable, the reporting disagrees with finance, nobody trusts the forecast, and half the useful context lives in email.

The complaints are legitimate. The diagnosis is not. A CRM is a system of record for what people typed into it, and it does that job adequately. What is missing sits above it.

What a CRM was designed to do

A CRM stores entities and the fields a human filled in. It is optimised for retrieving a record, editing it, and reporting on the fields. Those are the right goals for a system of record.

What it does not do — and was never designed to do — is model what actually happened. It does not know that the person who replied on Tuesday is the economic buyer, that the account went quiet for three weeks in March, that the champion changed jobs, or that the same company appears in the support system under a different name. Those facts exist in your systems. They are simply not in the CRM, and no migration puts them there.

Three things the layer above has to provide

Identity. One account, resolved across CRM, email domains, support, billing and product telemetry, including the cases where the names do not match and the domains have changed. Nothing downstream works without this, and it is the part most projects underestimate — it is not a fuzzy-match script, it is an ongoing reconciliation with a confidence score and a human review path.

A timeline. Every meaningful event on that account in order: emails, meetings, calls with what was said, stage changes with who made them, tickets with sentiment, usage shifts, invoice events. Not a feed — an ordered, queryable history you can ask questions of, like 'what happened in the two weeks before this deal stalled'.

Definitions. One place where qualified, active, at-risk, expansion-ready and churn are defined as computable expressions rather than as tribal knowledge, so every report, model and automation resolves them the same way.

The CRM knows what was typed. The semantic layer knows what happened. Only one of those supports a forecast.

The distinction worth a migration budget

Why migration feels like it works, briefly

A migration does deliver something real. It forces definitions to be agreed, it purges dead records, and it resets field sprawl. For about two quarters the data is cleaner than it has been in years.

Then the same forces reassert themselves — fields multiply, definitions drift, context accumulates in email — because none of the mechanisms that produced the original mess were changed. The migration reset the symptom and rebuilt the cause in a new schema, at considerable expense and with a quarter of lost productivity in the middle.

Build above, not instead

A layer above the stack has a property migration cannot offer: it survives tool changes. Swap the helpdesk, swap the billing system, and the identity graph, timeline and definitions persist. The adapters change; the model does not.

It is also incremental in a way migration never is. Connect the CRM and email first and you already have the majority of deal context. Add support and you can see retention risk. Add billing and usage and expansion becomes visible. Each step is independently useful, and no step requires anyone to stop working while it happens.

A practical readiness test: can you answer 'what happened on this account in the last ninety days' without opening more than one system? If not, the gap is the layer, not the CRM.

What this makes possible

Once identity, timeline and definitions exist, a set of questions that used to require an analyst become ordinary queries. Which deals behave like deals that closed. Which accounts look like the ones that expanded. What changed on this account before it went quiet. Which of our definitions actually predict anything.

None of that requires a new CRM. All of it requires knowing, reliably and in order, what happened — which is the thing nobody's system of record was ever asked to hold.

Solution engineeringDeployment & integration
data foundationCRMarchitectureintegration
See this running on your own pipeline.

Thirty minutes on your data — we map the lifecycle, show the system live, and estimate what is recoverable.

Book an executive briefing