Initial enthusiasm gives way to stalled adoption, consistently settling around 20%. It happens repeatedly across pilots and enterprise rollouts, and organisations struggle to understand why the pattern emerges so predictably.
The core issue is simple. Companies roll the tool out without redesigning the adoption systems that are meant to support it. The gap between deployment and sustained usage becomes the point where the whole thing quietly fails.
The real cost of getting stuck at 20%
For a 1,000-person organisation at 20% adoption, the unused licences cost roughly £240,000 a year. Beyond the licence spend, you forfeit the productivity: Microsoft's own research puts Copilot users at 10 to 12 hours saved a month.
The political cost compounds it. When a board-approved transformation fails to gain traction, the next technology decision faces more scepticism. And blame is hard to assign fairly, because the tool works, users attended the training, and the implementation followed best practice.
What happens after a rollout, months one to six
- Months 1 to 2. IT deploys licences, L&D delivers training, comms announce the initiative. Early adopters experiment and the metrics look promising.
- Month 3. Training ends and executive attention moves on. Users are on their own with no feedback loop, and nothing has redesigned the workflow to make Copilot the path of least resistance.
- Months 4 to 6. People quietly revert to familiar tools. Leadership stays unaware until board reporting prompts someone to look at the data.
The distinction that matters: implementation planning handles the mechanics of the rollout, but adoption systems create the conditions where sustained use becomes the easiest path.
The five pieces that go missing
- Manager modelling. People adopt the tools their managers visibly use. A manager who skips the training sends a louder signal than any encouragement email. When managers use it in meetings and share what they are learning, adoption follows.
- Workflow integration. Adding a capability without redesigning the workflow creates friction. If the team lives in Salesforce, Copilot has to meet them in Salesforce. Forcing people out of their workflow to reach the tool guarantees they stop.
- Permission clarity. Vague guidance paralyses cautious people. "Use it responsibly" freezes them. Explicit boundaries free them: "you can use Copilot for internal documents and email drafts, but not for client contracts pending legal review." Clarity is what enables experimentation.
- Feedback loops. Without reinforcement, early experiments feel like failures and people default to giving up. A Slack channel, office hours, or a team check-in normalises experimenting and speeds up peer learning.
- Measuring value, not logins. Tracking access masks the real picture. A celebrated "45% adoption" can turn out to be one-time logins. Measure whether the tool actually saved time or improved the work.
Why leadership misses it
Leadership optimised for rollout-completion metrics and never measured adoption-system readiness. They measured licences deployed, training delivered, comms sent, governance published. They should have measured whether managers understood their modelling role, whether workflows had been redesigned, whether people had permission clarity, whether feedback loops existed, and whether anyone was measuring value at all. Adoption systems stay invisible until their absence shows up in the numbers.
Three assumptions that kill it
- "Training equals adoption." Training explains how the tool works, not why sustained use is easier than reverting to the old way.
- "If people need it, they'll use it." Only frictionless use survives a busy week. When the legacy method takes less effort, people default to it under pressure.
- "Technology problems have technology solutions." This is an organisational design failure, not a technology one. The same gap would sink any new system.
What actually changes it
- Make adoption a leadership accountability, not optional encouragement. Managers model the usage visibly.
- Redesign the workflow, not just bolt on a capability. One firm added a 60-second slot to the daily stand-up where someone shared how they had used Copilot, and usage rose 34% in six weeks through peer learning.
- Write the permission boundaries down. Specificity enables experimentation. Ambiguity kills it.
- Build feedback loops. Weekly check-ins that normalise experimenting do more than the training ever did.
- Measure value, not activity. One firm switched from "daily active users" to "tasks that demonstrably saved time", and the quality of adoption climbed.
What will not fix a stalled rollout
More training produces the same result when the system design is unchanged. Mandated usage buys compliance, not capability. Champion evangelists are useful for answering questions but powerless against a system-design problem. And waiting for product updates is a category error, because features fix capability gaps, not system design.
When 20% is actually fine
If you deliberately concentrated Copilot on the roles with the highest return, the analysts and content creators, then 20% is a rational outcome. But most organisations rolled out broadly and expected broad adoption. The diagnostic question is simple: did you design for 20%, or did you get stuck at 20%?
If your rollout is stuck, that is exactly what the AI Embedding Diagnostic is for: a short, honest read on where it actually broke. Human organisations need human-centred system design, not better deployment mechanics. The fuller case for treating AI capability as an organisational design problem is in what it takes to build AI capability.