AI adoption: watching people not use a system that works
The most common outcome of an AI project is not failure in any technical sense. It is a system that works correctly, was delivered on time, meets its acceptance criteria, and is not used. Everyone involved did their job and the organisation got nothing, which is a more expensive result than a project that visibly fails, because it also consumed the credibility needed to try again. The reasons people abandon a working system are consistent across industries and are almost never the ones given when they are asked. It is three clicks too deep in a tool they do not otherwise open. It does not show the one number they are personally accountable for. It was wrong once, in front of their manager, and they have not trusted it since. None of those appear in a requirements document and all of them are visible in twenty minutes of watching.
Watch, do not ask
Asking people why they are not using something produces polite, plausible answers that are usually wrong, and not because anyone is being evasive. People are poor at introspecting about friction, and the real cause is often something they would consider too trivial to mention.
Sitting beside someone while they do the work, in their normal conditions, surfaces it quickly. The hesitation before opening the tool. The tab they go back to instead. The moment they copy the output somewhere else because that is where the rest of their work lives.
Twenty minutes each with four people will tell you more than a survey of forty. The output of this exercise is a list of small changes, most of which take a day, and it is the cheapest quality work available at this stage of a project.
The three causes that account for most abandonment
It lives somewhere they do not. A system in its own interface competes for attention with everything else open on the screen. One that appears inside the tool people already use does not have to be remembered, and the difference in sustained use is large enough to be worth substantial engineering.
It does not speak to their accountability. People act on what they are measured on. Output that is correct but does not connect to the number on their dashboard gets treated as someone else's project, and no amount of accuracy changes that.
It lost trust once. A confidently wrong answer in front of a colleague is remembered far longer than a hundred correct ones, and the recovery is slow. This is the strongest practical argument for designing systems that show uncertainty: a system that hedges when it should lasts longer than one that is marginally more accurate and uniformly confident.
Find the person who already wanted this
Every organisation has someone who has been arguing for this change for two years and getting nowhere. They are usually not senior and they are always identifiable within a week of asking.
A deployment that makes that person look right propagates by itself, because they will tell people, defend it when it is criticised, and keep using it when the vendor has gone. A deployment that makes the vendor look clever stops the day the vendor leaves.
The corresponding discipline is to give away the credit deliberately. The project's success should be attributable to somebody who works there, and the people who do this instinctively get a second engagement far more often than the ones who present well.
Measuring adoption without lying to yourself
Logins are not adoption. Neither are sessions, and neither is anything a dashboard produces by default, because all of them count people opening a thing rather than people relying on it.
The number that means something is the share of the real work that went through the system, measured against the total volume of that work from a source the system does not control. If four hundred cases were handled last month and the system touched ninety, that is the figure, and it is usually lower than anyone expected.
Budget it like a stage, not a launch
A reasonable planning assumption is that a system takes about as long again after go-live to become genuinely used as it took to build. Almost no plan reflects that, which is why adoption is usually attempted with whatever attention is left over.
The comparison between markets is instructive here. Reported patterns in Japan describe decisions taking longer to reach and then meeting much less resistance, which is close to the mirror image of markets where a sponsor decides quickly and adoption is a prolonged negotiation with people who were not consulted. Plans built for one pattern misjudge both halves of the other. Our Japan page covers that in more detail.
What travels everywhere is the sequencing: the person whose work changes is involved in week one or the project pays for it in month four.
If something works and nobody uses it
That is a specific problem with specific causes, and it is usually fixable in days rather than requiring a rebuild. It is one of the more useful first conversations to have.
A first conversation is thirty minutes and is not a sales call. If the answer is that you do not need us, that is a useful outcome and we will say so.
