Rolling it out to people who did not ask for it
You have a working thing, measured, with a policy and a checkpoint. Now you have to get thirty people to change how they work, and most of what determines whether that succeeds has nothing to do with the technology.
Start with the fear, because it is there
Some fraction of your team believes this is the beginning of their job disappearing. They will not raise it. They will express it as scepticism about the tool's quality, which is much easier to say out loud, and you will spend three weeks debating features while the actual conversation goes unhad.
Name it first, in a group setting, plainly. What this changes about the work. What it does not. Whether roles are affected, answered honestly.
If the answer is "this is about capacity, not headcount", say it and mean it — and understand that your credibility on this is spent once. If you say it and then reduce headcount in eight months, nothing you announce afterwards will be believed, by anyone, for years.
If the answer is that roles change, describe how, and what support exists. People handle bad news considerably better than uncertainty. Uncertainty produces exactly the quiet non-adoption that kills deployments while everyone reports that things are fine.
Champions, not mandates
A mandate produces compliance behaviour: people use the tool while being watched and revert when they are not, and your usage metrics look fine while nothing has changed.
What works is two or three people from the pilot who genuinely found it useful, showing colleagues their actual work. Peer demonstration on real tasks beats any training session, because the objection in most people's heads is "that won't work for the kind of thing I do", and only a colleague doing that kind of thing can answer it.
Kavita's most effective moment was a reviewer showing the team a claim file she had summarised — including one where the tool got it wrong and how she caught it. That single example did more for adoption than the vendor's training day, because it was honest, and honesty about failure is what makes claims about success believable.
Training that is not a webinar
Train on their work, not on the tool. Sessions built around the three tasks people actually do, with their own files.
Small groups, hands on keyboards. Twenty minutes of doing beats an hour of watching.
Give them the failure cases. People trust a tool more, not less, when they are told where it fails. The reviewer who knows about the prior-claim problem checks for it. The one who was told it is 92% accurate has no idea what to look for and either over-trusts or under-trusts, both of which are expensive.
Write a one-page how-we-use-this. The three approved uses, the checkpoint, the traffic light, who to ask. One page, near the work.
The two people who refuse
You will have them. Distinguish two cases, because the responses are opposite.
The one with a substantive objection. They have noticed something real — it does not work for their sub-process, or it introduces a risk you have not addressed. These people are enormously valuable and are usually right about something specific. Get the objection precisely, and either fix it or agree an exception.
The one who does not want to change. Different problem, and not a technology problem. Handle it as you would any other change to how work is done — with clarity about what is expected, support to get there, and the same standards you apply to anything else.
Confusing the two is the common error. Treating a substantive objector as a resister loses you the person most likely to prevent an incident.
Set the expectation about quality correctly
The framing that works: this produces a good first draft, and you are accountable for what goes out.
That sentence does two things at once. It tells people the tool is genuinely useful, so they engage with it. And it locates the accountability where it actually is — with them — which is both true and the only framing under which the checkpoint gets taken seriously.
The framing to avoid at all costs is "the AI handles this now". It is false, it makes checking feel like distrust of the machine rather than part of the job, and it is precisely the belief that produces the rubber-stamp failure from lesson 9.
Do this today: ask three of your people, one to one, what worries them about this. Do not defend anything; just listen and write it down. Whatever comes back is your rollout plan.