CRM adoption is a design problem before it is a training problem
Build for the person’s ordinary Tuesday, give each process a business owner, and measure use, not logins.
When a new system goes unused, the usual answer is more training. Usually it was designed for the report, not the person’s Tuesday. What we change instead.
The call comes about four months after go-live. The system is in, the data is in, the training was delivered, and the sales team is not using it. Could we run another session.
We can, and sometimes we do. But in most of these cases the second training session teaches people how to use a system that was designed to make someone else’s job easier, and no amount of instruction changes what a system is for. Adoption is decided at design time, and here is what deciding it well looks like.
Design for the person’s Tuesday, not for the dashboard
Most CRM configurations are built from the report backward: the leadership team wants a pipeline view, so the fields that feed it become required, and the person entering an opportunity fills eleven fields to record a phone call. The dashboard is excellent. The person stops recording phone calls.
The design has to start from the other end. What does a salesperson, a service agent or a project manager do on an ordinary Tuesday, and what would make that hour shorter? If logging the call takes longer than the call, the system has to change, not the person. Fields that exist only for the report are pushed to later stages, defaulted or derived. The dashboard is still excellent — it is fed by people who are using the system because it helps them.
Give the work an owner who is not IT
Every process that lives in the CRM has a process owner: a person on the business side who decides how the process works, signs off changes to it, and is the one who says “yes, this is how we do it now” to their own team. When the process owner is IT, or the consultant, the team experiences the system as something done to them. When the process owner is their own manager, it is how the team works.
This is why our discovery calls include the process owners and not only the sponsor. A system designed with the people who will run it is a system they have already agreed to use.
Remove the parallel system on purpose
If the spreadsheet is still available, the spreadsheet wins. It is familiar, it is fast and nobody is watching. Adoption needs the old path closed: the report that used to come from the spreadsheet now comes only from the CRM, the weekly meeting runs from the CRM screen, and the data that used to live in email lives in the record. This is a management decision, not a technical one, and the projects where it was not made are the projects that called about training.
Train on the person’s own work, in the first week
Training still matters — but as the last step, and in a specific form. Not a tour of the system: a session where each person brings their real accounts, real open deals and real service cases and enters them, with someone beside them who can change a field label or a default on the spot when it turns out to be wrong.
The first week of use is when the small frictions appear, and the difference between a system that is adopted and one that is abandoned is whether those frictions are fixed in that week or filed for a later phase.
Measure use, not logins
Login counts will be fine. Everybody logs in. The measure that matters is whether the work is happening in the system: are opportunities being updated within a day of a change, are cases being closed with the resolution recorded, is the pipeline report the one the sales director actually reads. These are questions about specific fields and specific reports, agreed at design time and checked in the first ninety days.
When one of them is not being met, the first assumption is that the design is wrong somewhere, and the fix is usually a field, a default or a stage — not a session.
What the second training session should be
A review, with the process owners, of the ninety-day measures: which parts of the system are carrying the work, which are being worked around, and what changes. Sometimes a training need does come out of that review. More often what comes out is a list of fields to remove.
That is adoption as we understand it. Not persuading people to use the system they were given, but giving them the system they would have asked for. It is also most of what our support work is.
Want this applied to your business?
Thirty minutes with a principal turns the general case into your specific list: which workflows, what they’re worth, and in what order. The article can only tell you what we would look at; the call tells you what we found.