By Ritvars Mētra, Founder of ReadinessCompassAsk a sales team why the CRM is not up to date and you will get answers about time. It takes too long, the forms are fiddly, there are too many required fields, it is easier on a laptop and they are in the car.
All of that is true and none of it is the reason. Time explains why an update is late. It does not explain why the notes are thin, the close dates cluster on quarter end, and three of the five biggest opportunities appeared in the system a fortnight before they closed.
What does not get updated is specific
The pattern is consistent enough across organisations to be diagnostic. It is not that the CRM is uniformly empty; it is that particular fields are unreliable in particular directions.
| What is unreliable | The direction of the error | What it protects |
|---|---|---|
| Opportunity creation date | Deals appear late | Room to work without being forecast against |
| Stage | Sticks at the middle stages | Avoids commitment and avoids admitting a loss |
| Close date | Clusters at period end | Matches the review cycle rather than the customer |
| Contact and note history | Thin, generic | Keeps the account non-transferable |
| Loss reason | “Price” | Ends the conversation quickly |
| Activity logging | Batched, retrospective | Effort not measured as a comparable number |
Every one of those is rational under the incentives most sales organisations actually run. And the “price” loss reason deserves special mention: it is almost always false, it is never challenged, and it destroys the single most valuable dataset a CRM could produce.
The arithmetic from a rep’s side
Consider what an honest update costs and returns.
Cost: fifteen minutes of selling time, plus exposure. An accurately staged pipeline can be questioned. A deal marked as slipping invites a conversation. Detailed notes make the account easier to hand to someone else.
Return, in most organisations: nothing that the rep experiences. The data goes up. Nothing comes back down.
That asymmetry is the whole problem, and it is why training does not fix it. Nobody has misunderstood the process. They have evaluated it correctly. The research is blunt about how far this can go: in the Journal of Marketing, Cheri Speier and Viswanath Venkatesh found that across 454 salespeople in two firms, sales force automation was widely rejected six months after implementation, with absenteeism and voluntary turnover significantly increased — despite positive perceptions immediately after training.
The death spiral
Incomplete CRM data is not a stable state. It degrades, through a loop that is easy to describe and hard to stop once it is running.
- Data is patchy, so the forecast built from it is wrong.
- Because the forecast is wrong, leadership builds a parallel one — usually a spreadsheet, usually maintained by a director.
- Because the real forecast lives in the spreadsheet, the CRM is visibly not the source of truth.
- Because it is not the source of truth, updating it is administration rather than work.
- So the data gets patchier.
The loop closes in about two quarters. The important feature is that step two — the parallel spreadsheet — is a reasonable management response to bad data, and it is also the thing that guarantees the data stays bad. Whoever maintains that spreadsheet has more influence over CRM adoption than the programme does.
What it costs, concretely
The cost is usually described as “poor visibility”, which is vague enough to be ignored. Four specific costs are worth putting in front of a sales director:
Forecast error becomes structural. If close dates cluster at period end because that is the review rhythm rather than the customer’s buying cycle, the forecast is not a prediction. It is a restatement of the calendar, and every downstream plan built on it — hiring, inventory, cash — inherits the error.
Handovers fail. Thin note history is invisible until someone leaves, goes on parental leave, or an account is reassigned. Then the organisation discovers that the relationship was never held by the organisation at all. This cost lands entirely on the customer, who is asked to re-explain their situation to someone new.
Nothing can be learned. With loss reasons recorded as “price”, no analysis can distinguish a pricing problem from a product gap, a slow response, or a competitor with a better implementation story. The most commercially valuable question a company can ask — why do we lose — is unanswerable from its own data.
Every later initiative inherits it. Territory design, account scoring, pipeline analytics and increasingly anything AI-assisted all run on this data. A model trained on a pipeline where stage means “how the rep feels about scrutiny” will produce confident output about nothing.
Why activity targets make it worse
The standard response to poor logging is to set a logging target. Fifty activities a week, and compliance reported by manager.
This reliably produces fifty activities a week and no improvement in data quality, for a reason Donald Campbell described in 1979: the more any quantitative indicator is used for decision-making, the more subject it becomes to corruption pressures, and the more apt it is to distort the process it was meant to monitor. An activity count is unusually easy to satisfy without doing the underlying thing.
Worse, it confirms the surveillance reading. A team that suspected the CRM was there to measure them has now been told so explicitly, which suppresses exactly the honest, unflattering data — the slipping deal, the real loss reason — that would have been most useful. This is the same trap that makes any criterion satisfiable without the underlying thing being true worthless.
What changes the behaviour
- Close the parallel forecast. Not a communication exercise — a decision that the monthly review is run from the system, with whatever data exists, including the embarrassing gaps. One painful review does more than a quarter of encouragement.
- Make the system give something back. A renewal alert, a genuinely useful call list, a warning that a key contact has gone quiet. If reps would notice its absence, the asymmetry is broken.
- Reward the update that hurts. The rep who moves a deal backwards a stage, or logs an honest loss reason, is doing the single most valuable thing in the system. If that is met with scrutiny rather than thanks, the behaviour ends immediately and permanently.
- Cut the fields to what is actually used. Every required field that feeds no decision is a tax that teaches people the system is not serious. If nobody has read it in a year, delete it.
- Have managers work in the system. Their visible use is the intervention with the best evidence behind it, and it needs to be specific rather than exhortative.
None of these are CRM configuration changes. That is the point — the problem was never in the configuration.
More on adoption evidence and behavioural risk in the Adoption Risk Hub, or see which pipeline measures actually indicate adoption after go-live.