Twelve weeks after go-live the CRM adoption dashboard reads well. Weekly active users at 94 per cent. Records created up. Training completion closed out at 98 per cent.
In the same twelve weeks, the sales director has continued to build the forecast from her own spreadsheet, because the pipeline in the system is not something she would put in front of the board.
Both facts are true. The dashboard is measuring whether people log in. Nobody is measuring whether the data can be relied on, which is the only thing a CRM exists to produce.
Why the usual measures fail
Logins, record counts and activity volumes share a property: they can all be satisfied without the underlying thing being true. A rep who opens the system on Thursday to update six opportunities before the Friday review appears in every one of those metrics as an engaged user.
Worse, once such a measure is reported upward it starts to shape behaviour rather than describe it. Donald Campbell’s 1979 observation applies directly: 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. Set a target on activity logging and you will get activity logging.
A useful pipeline measure has the opposite property. It should be hard to satisfy without actually doing the work, and it should be capable of getting worse.
| Commonly reported | What it establishes | Better question |
|---|---|---|
| Weekly active users | People opened the system | How soon after a real event does the record change? |
| Records created | Rows exist | Do the rows describe reality? |
| Activities logged | A target was met | Would anyone act on this differently if it were absent? |
| Training completion | People were processed | Can a manager run their pipeline review from the system? |
| Data completeness % | Fields are populated | Are they populated with anything informative? |
The last row is the one that catches teams out. A required field with a default value reaches 100 per cent completeness and carries no information at all. Completeness is a measure of enforcement, not of quality.
Six measures that indicate real adoption
1. Update latency. The time between something happening with a customer and the record reflecting it. This is the single best pipeline hygiene measure, because it cannot be gamed by batch updating — batching is the failure it detects. A distribution clustered on the day before the review tells you the CRM is a reporting exercise, not a working tool.
2. Backward stage movements. Count how often deals move down a stage rather than up. In an honest pipeline this happens regularly, because deals genuinely regress. A pipeline where opportunities only ever advance or vanish at quarter end is not being maintained; it is being curated. This is the closest thing to a direct measure of psychological safety in the system.
3. Loss reason distribution. If more than half your losses are recorded as “price”, the field is being used to close a conversation rather than to record one. A healthy distribution is spread across several reasons, including uncomfortable ones like “no decision” and “we were too slow”. This measure has the useful property of being immediately actionable when it improves.
4. Forecast accuracy computed from system data only. Not from the director’s spreadsheet. Take what the CRM said at the start of the period and compare it with what closed. The absolute accuracy matters less than the trend: if it is not improving, nothing else on the dashboard means anything.
5. Manager system-use rate. Whether managers run reviews from the system, pull their own reports, and comment in the record rather than by email. This is a measure of the intervention with the strongest supporting evidence: in the Journal of the Academy of Marketing Science, Christian Homburg, Jan Wieseke and Christina Kühnl found that salespeople observing superiors use sales technology showed strengthened willingness to adopt it, with superior and co-worker adoption positively affecting ongoing use.
6. Existence of a parallel forecast. Binary, and the most honest measure available. If a spreadsheet forecast still exists anywhere and is used in any decision, CRM adoption is not complete regardless of every other number. It also tends to be the measure nobody wants on the dashboard.
Measure at six months, not at six weeks
The timing convention in most programmes is backwards. Adoption is measured shortly after go-live, while hypercare support is still present and attention is high, and the resulting number becomes the reported outcome.
The evidence suggests that is the least informative moment. In the Journal of Marketing, Cheri Speier and Viswanath Venkatesh found that salespeople held positive perceptions immediately after training and that the technology had been widely rejected six months after implementation, with absenteeism and voluntary turnover significantly increased.
Whatever you measure, measure it again at six months, when the support has gone and the behaviour has settled into whatever it is going to be. Decay between those two points is the finding; the initial number on its own is not.
Do not carry it on one number
Any single adoption measure will eventually become the goal and stop describing the thing it stood for. The defence is to carry the construct on several measures that can disagree with each other.
“The pipeline is trustworthy” is evidenced by update latency, backward stage movements and forecast accuracy together. If latency improves while backward movements stay at zero, you have taught people to update faster without making it safe to be honest — a real finding, and one no single metric would have surfaced. It is the same logic that makes a composite readiness score more robust than its inputs.
A CRM dashboard reporting logins is measuring whether people complied. A dashboard reporting latency, honesty and forecast accuracy is measuring whether the organisation can now see its own pipeline — which is what was bought.
More on measuring adoption honestly in the Adoption Risk Hub, or see why particular fields go unreliable in the first place.
