Getting an AI tool adopted: the rollout plan, from pilot to retiring the old process

A delivered tool is not yet an adopted tool

The day an AI tool goes live, the technical part seems finished. Access is open, the documentation is online, an announcement email has gone out. Some time later the picture is often the same: a handful of people use it, the others carry on as before, and the old shared file is still the reference. The tool works. It simply has not entered the work.

There is nothing mysterious about this gap. An AI tool asks people to swap a routine they have mastered for one they have not, with added doubt about how reliable the answers are. As long as the old way is available, more familiar and felt to be safer, it wins. Change management means reversing that balance, step by step, for one specific tool and one specific team.

What this article covers

We deal here with rolling out a given tool: an assistant that drafts tender responses, an agent that prepares follow-up files, an application replacing a tracking spreadsheet. The broader question of how teams progress on AI, their stages of understanding and practice, is the subject of our article on bringing your teams up to speed on AI. The two go together: a more mature team adopts faster, but no amount of maturity replaces a rollout plan.

Preparing the ground before launch

Adoption is partly decided before go-live. Three points deserve attention at this stage, because they are much harder to fix afterwards.

Name the task the tool replaces

“Use the assistant” is not a goal. “Prepare the first draft of the technical response from the specification and our past responses” is one. The more precisely the task is named, the easier it is to train, to measure and to decide when the old process can go. If the task stays vague, the project framing often was too, a point we cover in our article on production prerequisites for a business POC.

Say what the tool does not do

Users distrust a tool presented only through its strengths. Stating its limits openly is more reassuring: it does not set prices, it signs nothing, it proposes a first draft that the person reviews and owns. CNIL, the French data protection authority, recommends familiarising end users with how generative AI systems work and where their limits lie, and getting them to check the quality of what comes out.

Review access rights

A tool connected to email or document storage sometimes inherits broader rights than it needs. ANSSI, the French cybersecurity agency, recommends reviewing these rights at activation, then regularly. An access incident in the first days would ruin the whole team's trust: better to prevent it before launch than explain it after.

Choosing pilot users

Opening the tool to everyone on the same day means discovering its flaws in front of everyone. A first circle of pilot users lets you fix what needs fixing before the tool is judged by those who view it with suspicion.

Who goes in the first circle

• People who do the task often, so feedback arrives quickly and rests on real cases.
• At least one respected sceptic whose opinion counts in the team. If convinced, they will convince others. If not, their objections are the ones to address.
• Varied profiles: seniority, digital confidence, types of cases handled. A pilot made only of enthusiastic volunteers paints too flattering a picture.

What is expected of them

The pilots' role is explicit: use the tool on their real cases, report anything wrong, and say frankly whether it saves them time or not. They must know criticism is expected. A pilot who does not dare say the tool is slow or its answers off the mark is of no use.

Training on real cases, not the demo

Classic training presents the tool on a prepared example where everything goes well. Users leave convinced, then get stuck on the first real case: the unreadable attachment, the customer listed twice, the request outside the expected scope. That is when they go back to the old method.

Start from the team's own files

Training that works uses the team's own cases, chosen to cover the common ones and a few hard ones. Everyone does the task on a case they know, compares it with what they would have produced alone, and sees where the tool helps and where they must take over. That is the logic of our training on deployed tools: short, in small groups, on real data.

Learn to recognise a bad answer

Part of the training must be about errors. Show a wrong but plausible answer, explain how to spot it, say who to report it to. A user who can recognise an error trusts the tool more, because they know they stay in control.

Leave a usable trace

A one-page sheet per task, with the steps, known pitfalls and the name of the go-to person, is worth more than a full manual. It gets read at the moment it is needed, in front of the case.

Naming go-to people in the teams

When a user gets stuck, they do not read the documentation or open a ticket. They turn to the person sitting next to them. Go-to people are exactly those people, identified and equipped.

The go-to person's role

• Answer everyday questions, on the spot and without delay.
• Escalate problems they cannot solve, with a precise example.
• Share good practices found by the team.
• Give an honest reading of real usage at follow-up meetings.

Give them time and recognition

The go-to person is not a volunteer handed an invisible extra load. Their manager recognises the role, part of their time is set aside for it, and they have a direct line to the team maintaining the tool. Without that, the role fades quickly and questions go unanswered.

Organising feedback and fixing fast

The period after launch decides everything. The first flaws will appear; that is unavoidable. What matters is the time between a user reporting a problem and seeing it has been dealt with.

One simple channel

A single feedback channel, one click away from the tool or in the team's usual messaging. Every piece of feedback gets an answer, even when the answer is “we will not fix this, here is why”.

Triage without letting things drag

Feedback falls into three categories: what blocks work and gets fixed straight away, what gets in the way and goes into the next version, and what is a new request to be discussed. This is where the forward deployed model makes sense: the engineer who built the tool is on site with users, sees the problem on their screen and can fix it without going through a chain of tickets. We describe this sequence in our article on deploying an AI agent step by step.

Show what changed

Every fix shipped is announced to users, citing the feedback that triggered it when the person agrees. Nothing encourages people to report problems more than seeing an earlier report acted on.

Measuring real usage

The number of accounts opened says nothing about adoption. What counts is the share of the target task that actually runs through the new tool, and what users do with the result.

Useful indicators

• The share of cases handled with the tool, compared with all cases of the same type over the same period.
• The keep rate: when the tool proposes a first draft, how often it is kept, edited or discarded.
• Regularity: do people come back, or does the trial go nowhere.
• Open feedback: how much, of what kind, and how long it takes to handle.

Combine figures and fieldwork

Indicators tell you where to look; they do not explain why. A team that barely uses the tool may have a good reason: a business case poorly covered, a step slower than before, a doubt about a piece of data. Spending time with them, on their cases, gives the explanation the numbers do not. It is also how you tell resistance to address from a flaw to fix.

Retiring the old process

This is the most often forgotten step, and the one that sinks the most rollouts. As long as the old file, form or procedure remains available and official, part of the team will stay with it. The organisation then lives with two parallel processes, duplicate data, and a tool that never becomes the reference.

Decide on announced criteria

Retirement is prepared from the start. You announce the criteria that will trigger it: the tool covers the common cases, blocking feedback is resolved, go-to people are in place, pilots confirm. When those criteria are met, the switchover date is set and communicated in advance.

Retire cleanly

• The old file goes read-only, then is archived, with a link to the new tool.
• Document templates, shortcuts and written procedures are updated.
• Exceptions are handled one by one, without reopening the old process for everyone.

When the tool replaces a spreadsheet that had become central, this moment needs particular care. Our article on replacing Excel with business software details the signs that the switch is ready.

Objections you will hear, and how to answer

“It's faster when I do it myself”

Sometimes true at first, and it should be acknowledged. The answer is to go through a complete case together, start to finish, counting the steps. If the tool genuinely saves no time on that task, that is feedback to act on, not resistance to overcome.

“I don't trust its answers”

A healthy distrust. Answer it by showing what the tool does and does not do, by recalling that the person reviews and approves, and by making visible the sources behind each answer where the tool allows. Trust is built on verifiability.

“They're preparing to replace us”

This concern deserves a clear, honest answer from leadership about what the project aims for. Our rollouts target specific tasks, the decision stays human, and the time the tool frees up should be visibly reinvested. Dodging the question only strengthens it. Our approach to change management starts with exactly this conversation.

The rollout checklist

• The replaced task is named in one sentence and shared with the team.
• The tool's limits are written down and announced.
• Access rights were reviewed before launch.
• A first circle of pilots, including at least one sceptic, uses the tool on real cases.
• Training uses the team's cases, errors included, with a one-page sheet per task.
• Go-to people are named, with time and a direct line to the technical team.
• A single feedback channel exists, and every piece of feedback gets an answer.
• Real usage is measured on the target task and checked against fieldwork.
• Criteria for retiring the old process are announced, and the switchover is dated once they are met.

This list applies whatever the tool's form: a complete business application, an agent, or a discreet automation. It fits into our broader way of supporting a project, from design to everyday use.

Where to start

If an AI tool has just been delivered and usage is not taking off, start with two questions: which precise task is supposed to run through this tool, and is the old process still available. The answers often explain most of it. If the rollout is still ahead, plan the first circle, the go-to people and the feedback channel before the launch date.

If you would like to look at your situation with us, our AI diagnostic starts from your teams' real usage and identifies what is holding back adoption of a tool, whether it is already in place or still a project.

Sources

• CNIL, Questions and answers on using a generative AI system (July 2024, in French)
• ANSSI, Security recommendations for a generative AI system (April 2024, French version), recommendation R35

Frequently asked questions

Should use of the new tool be made mandatory?

Not at the start. Until the tool has proved itself with pilots, imposing it turns every flaw into a grievance. The obligation comes naturally when the old process is retired, on criteria announced in advance and once blocking flaws are fixed.

How many pilot users should we plan for?

There is no right number in itself. The first circle should be broad enough to cover the variety of cases and profiles, and small enough for every piece of feedback to be followed personally. In a small team a few people are enough; in a larger department, one pilot per sub-team is a good guide.

Who should own the rollout: IT, the business or the provider?

The business owns the goal and the decision to retire the old process, because it is their work that changes. The technical team, internal or external, owns the quality of the tool and the speed of fixes. A single owner on the business side arbitrates when the two disagree.

What if pilots reject the tool?

Listen carefully to why. If the rejection is about fixable flaws, fix them and restart the pilot. If it is about the principle, because the tool saves no time on the target task, it is better to rethink the scope than to force the rollout. A pilot that reveals this has done its job.

Should staff representatives be involved?

As soon as a tool noticeably changes how work is organised, the question arises, and your legal counsel or HR can say what is required in your case. Beyond any obligation, involving them early lets you address concerns before they turn into opposition.