The rollout happened. The change did not.
You did the sensible things. The licences were bought, the tenant was configured, an announcement went out and a training session was well attended. Usage spiked, then settled. Now a handful of enthusiasts use the tool every day, most people open it occasionally, and a renewal or expansion decision is approaching with no clear view of what the money changed.
Buying more licences or running another round of training rarely fixes this, because neither addresses the reason people stopped. The reason is almost always specific to a team and a piece of work, and it is usually discoverable in a couple of weeks of looking properly.
Where adoption breaks
The friction usually falls into four groups. Each needs a different fix, so the diagnosis has to tell them apart.
- Access. The tool cannot see the material the work depends on, or it lives in a browser tab nobody opens during the task. People would have to copy and paste across three systems to use it.
- Trust and permission. Staff do not know whether they are allowed to put client names, figures or internal documents into it, so careful people avoid it. Or nobody has said who checks AI-assisted output, so using it feels like a personal risk.
- Fit. The tool was demonstrated on generic tasks. The team’s actual work, such as reconciling two reports or answering from a policy library, was never tried, and the first attempt went badly.
- Habit and time. Nobody has protected time to change a routine, and managers have not asked for the new way. The old way still works, so it wins.
Usage dashboards show that adoption is low. They rarely show which of these is the cause.
How the diagnosis works
I start with the paper trail: the rollout plan, the training material, the acceptable-use policy and the usage data your administrator can export. Then I spend time with one team: short interviews with regular users, occasional users and non-users, a conversation with their manager, and observation of the work itself. Watching someone do a task is often where the real answer appears, for example the moment they would need the tool but it cannot reach the document.
From that, I pick one recurring workflow with an existing reviewer and redesign it with the team: what goes in, which data is allowed, what the tool is asked to do, what the reviewer checks and when. The team uses it on real work while I am there, so the redesign is tested rather than theorised.
The signature deliverable, illustrated
You receive an adoption-friction diagnosis, one redesigned workflow and a repeat-use measurement plan. Illustrative extract from a diagnosis:
| Finding | Evidence | Type | Fix | Owner |
|---|---|---|---|---|
| Staff unsure whether client names are allowed | 7 of 9 interviewees raised it unprompted | Trust | One-page data rule for the team, signed off by data protection | Rollout owner |
| Tool cannot open the shared case files | Observed in 4 of 5 sessions | Access | Approved upload route for case files; review with IT | IT |
| Weekly status report never tried with the tool | Not in training material | Fit | Redesigned workflow, piloted this fortnight | Team lead |
Illustrative example. It shows the format, not a client’s findings.
The measurement plan defines repeat use for that workflow (who should use it, how often, and what counts), how to collect it monthly, and what level would justify extending the approach to the next team.
How acceptance is judged
The rollout owner accepts the diagnostic when the findings are evidenced, the redesigned workflow has been used on real work by the team, and the measurement plan has been run once with a baseline recorded. The licence recommendation follows from the evidence; it may be to hold, reallocate, expand or reduce.
Ownership and handover
The rollout owner owns the findings and the measurement plan. The team lead owns the redesigned workflow. I hand over the diagnosis, the workflow record and the measure, and walk the owner through running the first monthly check.
When this is the wrong page
If your problem is not one unused tool but several AI pilots with no owner and no path into daily work, that is a portfolio problem: use AI programme rescue, which starts with a different assessment and a different sponsor. If a specific AI application cannot ship, use AI application rescue. To spread the fix across teams afterwards, see the AI champions programme or a fractional AI enablement lead.