Adoption is an outcome, not a cause
When a CRM programme goes badly, the diagnosis is nearly always "adoption". That word is doing a lot of work, and most of it is concealment. It describes what happened — people did not use the system as intended — while implying the cause sits with the users.
It usually does not. Sales, service, and marketing teams are, as a group, ruthlessly pragmatic about tools. They adopt what makes their week easier and route around what does not, with impressive speed in both directions. A system with poor adoption is receiving accurate feedback about its fit.
Why do users route around a CRM?
Three reasons, in roughly this order of frequency:
- The system asks more than it returns. A rep enters twelve fields and gets nothing back that helps them sell. The data flows upward into a report they never see. This is the most common design, and it guarantees decay — every field that serves only management is a field maintained under duress.
- The workflow does not match the work. The system models an idealised process designed in a workshop, while the real process has exceptions, parallel paths, and handoffs the design never accounted for. Users hit the mismatch daily and build a workaround once.
- It is slower than the alternative. If logging an interaction takes ninety seconds in the CRM and five in a notes app, the notes app wins, permanently, regardless of policy. Speed is a feature and it is systematically under-weighted in CRM design.
Who should design the system?
The people who will use it, with authority — not consultation. There is a meaningful difference between showing users a design and asking for feedback, and giving users the power to reject a design. Only the second produces ownership.
The practical form is a working group with real representation: someone from each function that will use the system daily, alongside the managers and the implementation team. The users are there to say "this does not match how the work happens" and to be believed. Every organisation that skips this discovers the same objections after go-live, when changing them costs ten times more.
The failure pattern is consistent enough to name: a system specified by leadership, configured by IT or a partner, and handed to a team who see it for the first time in training. It is not that those people design badly. It is that they are designing for work they do not do.
What makes people actually use it?
Make the system return value to the person entering the data. This single principle resolves most adoption problems, and it is a design constraint rather than a change-management activity.
Concretely: the rep's own prioritised next-action list is generated from the fields they maintain. The service agent's escalation context appears because someone upstream logged it, so logging becomes visibly reciprocal. Commission and quota attainment calculate from the same records, so accuracy has a personal consequence. When the data loop closes back to the person supplying it, enforcement becomes largely unnecessary.
- Audit every required field and delete the ones that serve only reporting — typically a third of them
- Instrument how long common tasks take, and treat anything slower than the workaround as a defect
- Surface derived value back to users: next actions, account alerts, commission visibility
- Enforce the few process rules that matter in the system itself — stage exit criteria, staleness escalation — rather than in training that decays
What about training?
Necessary, routinely over-relied upon, and the standard substitute for design work. Training is how organisations attempt to make people accept a system that does not fit, and it does not survive the first busy quarter.
Where training earns its cost is narrow and role-specific: the two or three workflows a person actually performs, taught in the context of their week, shortly before they need them. What does not work is the comprehensive platform tour delivered to everyone at go-live, forgotten within a fortnight, generating the support load that then gets misread as resistance.
The rollout sequence that works
Start narrow and prove value before expanding scope. A CRM that does three things reliably for one team earns the right to do thirty things for six teams. The reverse order — comprehensive launch across all functions simultaneously — puts every unresolved design problem in front of every user on the same day.
Pick the team with the most acute pain and the most influence over their peers. Design with them, ship a narrow system that visibly makes their week better, and let demand come from the teams watching. Adoption driven by observed value costs nothing to sustain; adoption driven by mandate requires permanent enforcement, and quietly erodes the moment attention moves elsewhere.