AI adoption is a workflow problem before it is a training problem

The usual rollout goes like this. Licences are bought for the team. A session is booked, someone demonstrates the tool, everyone agrees it is impressive. Three months later two people use it daily, one uses it occasionally, and the rest have gone back to what they did before.

The conclusion drawn is almost always "we need more training". Usually that is wrong. The people who stopped using it are not confused about how it works. They tried it, it did not fit the shape of their day, and they returned to the thing that did.

Access is not adoption

A tool gets adopted when using it is the easiest way to do the work. Not the best way — the easiest. That is a higher bar than it sounds, because the existing way has an enormous advantage: it is already a habit, and habits cost nothing to run.

So a new tool has to be better by enough to overcome the cost of remembering it exists. For most people, most of the time, opening another tab, thinking of the right prompt, reading the output, editing it, and pasting it back is not obviously easier than just writing the thing.

That is the whole problem, and no amount of training solves it. Training teaches capability. The gap is friction.

Put it where the work already happens

The rollouts that hold have one thing in common: the tool is not somewhere else. It is inside the thing the person already had open.

The draft reply is already in the draft box when they open the enquiry. The summary of the call is already attached to the record. The product description is already written into the field, waiting to be corrected. The person's job changes from generating to approving, which is a smaller, faster, more comfortable job — and one they are qualified to do, because judging whether something is right is exactly what their experience is for.

This is also why it is a workflow question rather than a tooling question. The tool was never the hard part.

Decide what "good" looks like before you scale it

The second failure is subtler. A team adopts a tool enthusiastically, output triples, and quality quietly falls — because nobody ever wrote down what an acceptable output was, so every person is applying their own standard, and the standard drifts downward whenever anyone is busy.

Before a tool goes near a customer, somebody has to answer three things:

• What does a good one look like? Write two examples.
• Who checks, and when?
• What must never be sent without a person reading it?

Ten minutes of work. It is the difference between a team that trusts what comes out and a team that has quietly stopped reading it.

Expect three groups, and plan for all three

Every team splits the same way.

The enthusiasts, who were using it before you bought it. They need boundaries, not encouragement — they are the ones most likely to paste something confidential into a tool nobody vetted.

The pragmatists, the majority, who will use it if it is obviously easier and ignore it otherwise. They decide whether the rollout succeeds, and they respond to friction, not enthusiasm.

The sceptics, who have concerns. Some are about quality, some are about their job, and it is worth being straight about which. A sceptic with a quality concern is frequently your best reviewer. A sceptic who is worried about their job will not be reassured by a demonstration.

If a tool is only used by the people who would have found it anyway, nothing has been adopted. Something has just been purchased.

A rollout that tends to work

One team. One task, chosen because it happens often and gets reviewed anyway. The output appears where the work already happens. A named person owns quality. Four weeks. At the end, one question, answered honestly: did this make the work better, or only faster?

If the answer is yes, the next team is easy — you will have examples, a standard and somebody who can say what actually changed. If it is no, you have spent a month and learned something true about your business, which is considerably cheaper than a year of licences nobody opens.