Why doesn’t our CRM reflect reality?
A CRM records what people remember to type. It stores assertions — a lifecycle stage someone set once — rather than inferences the system re-derives when new evidence arrives. The gap between the CRM and reality is therefore a design problem, not a hygiene problem, and data-cleanup projects treat the symptom rather than the cause.
Stages are assertions. States are inferences.
A lifecycle stage is something a person asserted, once. Someone moved the record to Engaged in March. Nothing has re-examined that claim since. It can remain wrong for a year and the system has no mechanism for noticing, because it was never designed to have an opinion — only to store one.
A state is different in kind. It is derived from evidence, and it is re-derived when the evidence changes. If headcount moved, a competitor was mentioned, the champion left, or the account went quiet for sixty days, the state changes because the inputs changed — not because someone remembered to update a field.
Your CRM is full of the first and almost none of the second. That is the gap you are seeing, and it is a design decision rather than a discipline failure.
Why hygiene projects don't hold
Cleanup fixes the values. It cannot fix the mechanism that produced them. Manually maintained fields begin decaying the moment they are set, and no amount of enforcement changes the underlying economics: the person best placed to update the record is the person with the least incentive to.
The diagnostic is whether it has happened before. A first cleanup is maintenance. A third is evidence that the field is structurally unmaintainable and should be derived instead of typed.
Notice the shape of the ask: get the reps to update the CRM is a request for humans to do continuous observation and classification — the two things machines are unambiguously better at, and humans reliably worst at.
What CRM architecture actually means
Not a different CRM. A layer around it that answers four questions the CRM cannot answer on its own:
- What do we know? Which facts arrive without a human typing them.
- What can we infer? Which states those facts support, and with what confidence.
- What changed? Which transitions are worth detecting, and how quickly.
- What happens next? Which change triggers which action, by whom or what.
The CRM stays the system of record. It stops being asked to serve as the system of inference, which is the role it has been quietly failing at.
What changes when you fix it
The specific symptoms resolve together, because they share a cause:
- Scoring becomes trustworthy, because a rep can see what the score is derived from.
- Intent signals get used, because they change a state rather than landing in a report.
- Sales and marketing stop disagreeing about "qualified" — it becomes a derived condition, not a negotiated one.
- Stale records stop mattering as much, because the fields that drive decisions are computed.
Those are usually four separate items on a roadmap. They are one architectural problem, which is why fixing them individually has not worked.
Where to start
Pick one state that matters commercially — actively evaluating, say — and write down what evidence would justify inferring it, what would falsify it, and what should happen the moment it becomes true. Most teams cannot complete that exercise for a single state, and discovering that is worth more than another cleanup sprint.
The full version, across all six layers, is the GTM Architecture Audit. The distinction it turns on — architecture versus operations — is why this keeps coming back.
Will a data hygiene project fix it?
It will improve things for roughly a quarter. Cleanup corrects the values currently in the fields; it does not change the fact that those fields are populated by hand and decay from the moment they are set. If the same project has now run three times, the problem is structural rather than behavioural.
Is this an argument for replacing our CRM?
Almost never. The CRM is usually a reasonable system of record being asked to serve as a system of inference, which it was not designed to be. The fix is architectural — add a layer that derives state from evidence and writes it back — and it is considerably cheaper than a migration.
What is the difference between a lifecycle stage and a state?
A lifecycle stage is an assertion: someone set it, at a point in time, and nothing re-examines it. A state is an inference: the system derives it from evidence and re-derives it when the evidence changes. A stage can be wrong indefinitely without anything noticing. A state is wrong only until the next observation.
Our reps say they do not trust the data. Is that the same problem?
It is the same problem downstream. Trust follows from a field being derived and inspectable — a rep can see why the system thinks what it thinks. Fields that are manually maintained and silently stale earn distrust correctly, and asking reps to try harder does not address the reason they are right.