The short version
People abandon a tool that is slower than their existing workaround, that they have to remember to open, that gave them one bad answer they could not have caught, or that they were never given a reason to prefer. Fix the friction and the trust, in that order, and stop measuring licences.
What does the usage data actually tell you?
Look at the shape rather than the total. A spike in week one followed by decay is curiosity, not adoption — everybody tries a new thing once. What matters is the floor it settles at and who is standing on it.
If usage concentrates in a handful of people, you have enthusiasts rather than a deployment. Those people are useful, because they can tell you exactly what the rest of the team hit that they pushed through. That conversation is worth more than any survey.
Reason one: it is slower than the workaround
People are ruthless about this and they are right to be. If the existing way takes ninety seconds and the new way takes two minutes including opening a tab, logging in, pasting context and checking the answer, the new way loses — regardless of how much better the output is.
Time the whole journey, not the model. Most of the cost is around it: switching applications, finding the source material, copying it in, and verifying what comes back. A deployment that sits inside the tool people already have open beats a better one that requires a detour, every time.
Reason two: they have to remember it exists
Anything requiring someone to think “I could use the AI for this” will be used by the people who already think that way and nobody else. Memory is a terrible distribution mechanism.
The fix is to put it where the work already happens. A draft that appears in the ticket, a summary attached to the document, a suggestion in the tool being used — these need no recall at all. The difference in adoption between "available" and "already there" is enormous and it is a deployment decision rather than a training one.
Reason three: it was wrong once, invisibly
This is the big one. If someone acts on an answer, it turns out to be wrong, and they could not have told from looking — that person is finished with the tool, and they will tell their colleagues. One such incident propagates faster than any amount of positive experience.
Which is why showing sources matters more than accuracy in the range most systems occupy. An answer with a citation can be checked in seconds and a mistake is caught before it costs anything. An unsourced answer is either trusted blindly or verified from scratch, and both of those eventually end the same way.
If your usage collapsed suddenly rather than gradually, look for the incident. There usually is one, and someone in the team can tell you what it was.
Reason four: nobody was given a reason
A rollout that consists of an announcement, a licence and a training session teaches people what the tool does. It does not tell them why their Tuesday will be better, and it does not address the question most of them are actually holding, which is whether this is about replacing them.
Unaddressed, that question resolves as quiet non-adoption — nobody refuses, they simply do not prioritise learning something that might make them less necessary. Naming it directly, and being specific about what happens to the time saved, changes behaviour more than any feature walkthrough.
Is it the wrong tool, or the wrong deployment?
Usually the deployment, and the test is straightforward: find someone who does use it and watch them work. If a person doing the same job as everyone else gets real value, the capability is there and the problem is friction, visibility or trust.
If even the enthusiasts have quietly stopped, or they are using it for something other than the purpose you bought it for, that is a different diagnosis — the tool may be fine and aimed at the wrong task.
How do we recover it?
Narrow rather than broaden, which is the opposite of the usual instinct:
- Pick one team and one task where the value is obvious, and make that work properly before anything else.
- Remove every step you can. Pre-load context, put it where the work happens, cut the logins.
- Add sources to every output so people can verify cheaply.
- Find the incident that broke trust and fix the class of failure, then say so publicly.
- Ask the non-users, not the enthusiasts, what stopped them. They will tell you, and it is usually mundane.
Broad rollouts to unconvinced teams tend to produce a second, lower spike. One team using something daily is a foundation; twelve teams using it occasionally is a renewal conversation you will lose.
What should we measure instead of licences?
Weekly active users as a proportion of the intended audience, and the number of people who used it in four consecutive weeks. That second figure is the honest one, because it excludes the trying-it-out traffic that flatters every early report.
Then measure the outcome the tool was bought for — handling time, throughput, error rate. If usage is healthy and the outcome has not moved, you have adoption without value, which is a different and more awkward problem: people are using something that is not helping, and eventually they will notice too.
When is it right to switch it off?
When you have fixed the friction, added the sources, narrowed to one team, addressed the trust incident, and usage still will not hold. At that point the honest conclusion is that this task did not need it, and continuing to pay is a decision about not admitting that.
Switching off is not a failure if you learned where the value was not. What is expensive is the middle state most organisations sit in for years — a licence renewed annually, a handful of users, and nobody willing to be the person who cancels it.
Should we mandate it?
Rarely, and never as the first move. Mandating use of a tool people have rejected produces compliance theatre — the query gets run and the answer ignored — and it converts a fixable friction problem into a management one that nobody can measure.
The exception is where the tool is the process rather than an aid to it: if the ticket is drafted automatically and the agent edits and sends, there is nothing to mandate because there is no alternative path. That is a deployment decision, not a policy one, and it is why embedding beats instructing.
What does a good rollout look like?
Small, embedded and evidenced. One team, one task, the tool inside the software they already have open, sources on every output, and a named person who fixes things quickly in the first fortnight because early friction is what sets the pattern.
Then publish what happened internally, including anything that went wrong. A team that hears “this made an error last week, here is what changed” trusts the next claim. A team that only hears success stories stops listening, and quietly assumes the failures are being hidden.