IT Blog » AI » AI adoption is a people question, not a technology one

AI adoption is a people question, not a technology one

Most organisations have capable tools that hardly anyone uses, and the tool is rarely the reason.

Key takeaways

  • Expect rollouts to stall on people, because the common failure pattern is a few enthusiasts building something useful that nobody else adopts.
  • Stop mandating use, since a mandate produces compliance that ends the moment nobody is watching.
  • Build lasting habits through visible proof from a trusted colleague, low-stakes first tasks and repeat it until habits are formed.
  • Choose champions whose judgement colleagues already trust, even if they’re not the keenest on the technology.
  • Give adoption a named owner, so someone is accountable when uptake stalls.

At the first ramsac AI Summit in September 2026, the session on adoption brought a research perspective to a question the room kept circling. Organisations had bought capable tools, and while some people were using them brilliantly, most weren’t. The session asked why that happens so often, and what’s different about the organisations where it doesn’t.

The rollout pattern everyone recognises

The pattern is consistent enough to be predicted. A handful of enthusiasts find something genuinely useful and build a way of working around it. Word spreads, leadership is pleased, and the organisation announces it’s adopting the tool. Licences are bought for everyone.

Then nothing much happens. The enthusiasts carry on. Everyone else hears about the success, changes nothing about their own day, and develops a quiet resentment of the whole subject. Six months later somebody asks why the licences aren’t being used, and the usual answer is that people need more training.

Anyone who has run a rollout of any kind, technical or otherwise, will recognise this. What sets AI apart is how often the tool really is good, which makes the failure harder to diagnose and easier to blame on the users.

Why mandating use backfires

The instinctive response to slow uptake is to require it. Make the tool part of the process, measure who is actively logging in and then discuss it in one-to-ones.

This works, in the narrow sense that usage figures improve, However it can lead to compliance; people doing the minimum to register as using the tool, to satisfy measurement while it is being tracked. But once the attention moves elsewhere, usage may drop, and it leaves behind a workforce that now associates the technology with being monitored.

Worse, it destroys the signal you actually need. When usage is mandatory, you can no longer tell which parts are genuinely useful, because everyone is using all of it for reasons that have nothing to do with usefulness. Voluntary adoption is slower, but it shows you which parts people actually find useful.

What habit formation looks like at work

Organisations that get past the enthusiast stage tend to approach adoption the way you’d build any new habit, with repetition, cues and support over time, and three conditions came up again and again.

  1. Visible proof from someone the sceptics already trust. That’s usually the respected colleague who was unconvinced and changed their mind, because people tend to discount the office enthusiast.
  2. Low stakes, so trying it doesn’t feel risky. Early tasks should only cost a few minutes if they go wrong, such as tidying meeting notes or drafting an internal email.
  3. Enough repetition that it becomes the default. A tool used once a month never becomes a habit, so anchor it to something that happens every week, like a team meeting or a regular report.

All three are about people and routine, which is why so many capable tools go unused. They are also unglamorous enough that they tend to fall off the bottom of a rollout plan, underneath the licensing and the security review.

A champions programme that works at 50 to 250 staff

At this size, a formal change-management function is usually unavailable and probably unnecessary. What works is lighter, and it depends on choosing people well.

Pick one champion per team, chosen because colleagues trust their judgement, whether or not they’re interested in the technology. The enthusiastic early adopter is often the wrong choice, because their colleagues have already discounted their opinion on anything new. A respected sceptic is worth far more, and if they come round, that’s what will persuade everyone else.

Give each champion something small and concrete: a weekly win shared in the team’s own channel, in the team’s own language, describing a real task they’ve done. Keep the first tasks deliberately low-stakes. And give the champions somewhere to take the things that don’t work, because the organisations that hear about failures early are the ones that stop them becoming the story.

To see whether adoption is real, look at what people do. Surveys tend to capture what people think they should say, while the usage reports in Microsoft 365 show which teams have actually changed how they work and which are paying for licences nobody uses.

Common questions

How should a 50 to 250 person firm roll out an AI assistant?

Start with one team and one repeating task, then widen it. Choose a champion colleagues already trust, keep early tasks low-stakes, anchor use to something that happens weekly, and check the usage reports before extending it further..

Why do people stop using the tool after training?

Because training teaches capability and adoption requires habit. A session that demonstrates what a tool can do rarely changes what someone does on a Tuesday. Repetition against a real recurring task, with visible proof from a trusted colleague, does.

Should we make use of the tool mandatory?

It’s rarely worth it. Mandates produce compliance that stops when nobody is watching, and they remove the signal that tells you which parts are genuinely useful. Voluntary adoption is slower and considerably more informative.

Making adoption someone’s job

The practical failure underneath most of this is ownership. Licensing and security both have owners, but adoption is assumed to happen on its own, so when it doesn’t, nobody’s accountable for it.

Name someone and give them the champions, a small budget of time, and permission to report honestly on what is not working. The role isn’t technical and doesn’t need to be full-time, but it does need to exist. Without it, you’re left paying for licences that your people have quietly decided aren’t for them.

Handled well, the real return is what people do with the time they get back: more attention for customers and for the work that’s been waiting. Planning a Copilot rollout? Our Microsoft 365 Copilot readiness assessment plans your champions, first tasks and governance together, before features go live for everyone. If your question is bigger than one tool, our AI readiness assessment takes the same approach across the whole organisation.

Shall we talk it through? Book your Copilot readiness assessment with ramsac.