I have been called in to diagnose or rescue failed enterprise AI implementations more times than I can count now. The conversations always start the same way — “the platform is not delivering what we expected” — and they almost always end with the same finding.
The platform is fine. Something else failed.
What I actually find
Here is the pattern. A company buys an AI platform — Glean, Moveworks, Intercom AI, HubSpot AI, something in that category. Implementation happens. The system goes live. Initial usage is encouraging. Then over the following months, usage drops. Employees find workarounds. By the six-month mark, the platform is technically on but functionally ignored by most of the people it was meant to help.
The technology worked. The adoption did not.
And adoption failure is almost never a technology problem. It is a change management problem disguised as a technology problem.
Why adoption fails
Enterprise AI platforms require a behavioural shift from employees. They need people to trust a new interface, change an established habit, and believe — based on early experience — that this new thing will give them better results than whatever they were doing before.
Changing employee behaviour at scale is genuinely hard. It is hard even when the new thing is clearly better. People default to what they know.
The implementation model that most vendors sell — configure, train, go live — treats go-live as the finish line. It is not the finish line. It is the starting line for the actual work. The 30–90 days after go-live are where an implementation succeeds or fails, and those days are almost never included in the vendor contract.
Three things that determine whether adoption actually happens
Executive sponsorship that is visible. Not a message from the CEO at launch and then silence. Managers actually using the system. Leaders referencing it in team meetings. People noticing that their manager uses it to find things, and then trying it themselves. This sounds soft. It is the highest-leverage intervention I know of.
A feedback loop between real usage data and system tuning. You need to know, within the first two weeks of live usage, which query types the system is handling well and which it is failing on. Then you need to act on that — update the knowledge base, adjust the configuration, refine the flows. Most organisations collect this data and do nothing with it for months.
An internal owner who is measured on adoption, not on go-live. This person’s job is not finished when the platform is live. Their job is finished when usage is stable and growing. Measuring them on go-live creates go-live. Measuring them on adoption creates adoption.
What good looks like six months in
In implementations where these three things are present, the picture at six months looks like this: usage is growing rather than shrinking, the system has been updated multiple times based on real usage patterns, and employees are bringing requests for new use cases rather than avoiding the tool.
Getting there requires treating the implementation as having a long tail — not a delivery date. Every implementation we scope now includes a 30-day post-launch optimisation period as a non-optional component. It is not an upsell. It is where the value is actually created.
The platforms are good. The failure mode is almost never the platform.