Help the team use it
AI adoption strategy: help a team use the new workflow in everyday work
An AI adoption strategy explains how a team will use a new system in everyday work. It covers responsibilities, training, support and feedback after the first demonstration. Begin with the people carrying out the job: what changes for them, and how will they know the new route is worth using?
Make adoption part of delivery: people need a useful route through their work, an accountable support person and a way to correct the system.
Learn why people use the current route
Someone using an old spreadsheet may be protecting a client-specific detail that the new tool misses. Someone checking every draft may know that an apparently small error creates a long conversation with the client. Watch the job before deciding that the team needs more enthusiasm.
Said’s reporting example brings this into focus. Reporting varies by client, and maintaining all those requirements takes effort. A rollout that assumes one standard report can leave the team carrying the same complexity in an extra system.
Ask people to show a normal job and one awkward version. Record where the proposed workflow helps, where they still need judgement and what might make them revert to the old route. Explain which decisions remain theirs.
Agree the new responsibilities before rollout
| Part of the work | Responsibility to agree |
|---|---|
| Inputs | Who supplies and checks the information? |
| Output | Who decides whether the result is acceptable? |
| Exception | Who handles missing information or an unusual client request? |
| Support | Who responds when the system is unavailable? |
| Change | Who approves a new rule or corrected source? |
Give reviewers the evidence they need, including the original source and the system’s uncertainty. “A human checks it” is incomplete if the reviewer cannot see what was checked or has no time to do it.
Be clear about how released time will be used. If the team believes a new system simply adds review work, a demonstration of faster drafting will not answer their concern. Measure the complete job, including checks and corrections.
Train people through a real job and an exception
A useful training session ends with someone completing their own work. Use an approved example, then show what happens when information is missing, contradictory or outside the agreed scope. Practise the fallback route as carefully as the successful one.
Keep instructions close to the task. A brief guide beside an approval screen is easier to use than a slide deck buried in a folder. Give the team a contact who can change the workflow or get an issue to the person who can.
Begin with a group small enough that you can inspect its feedback. Expand when that group can complete the job reliably and support can handle the observed issues. The implementation roadmap covers build stages; this plan covers daily use.
Use feedback to change the workflow
Record a problem with the job, expected result and source information needed to reproduce it. Separate missing knowledge, confusing controls and incorrect behaviour. They need different fixes.
Review completed jobs as well as logins. Track whether people reach an acceptable result, how much review it needs and why they use another route. Use the same job definition before and after the change.
Show the team which issues were fixed and which need a decision. That closes the loop between reporting a problem and improving the system. Maintaining confidence in a workflow is an ongoing part of delivery.
Plan a rollout that the team can support
Worked example
Rolling out a reporting assistant
Invented teaching example. No client outcome is claimed.
FIRST GROUP
Two reporting roles try an invented report-preparation workflow with approved sample data.
RESPONSIBILITIES
The account owner confirms client requirements. A reporting reviewer approves the explanation.
TRAINING
Prepare a normal report, then repeat with an expired metric definition.
The expired definition goes back to its owner.
SUPPORT AND REVIEW
Record preparation, checking and correction time together.
Review the first jobs and fix missing client variations before adding more users.
Further reading
Written by Said Lopez, founder of LeverageAI and author of Lean AI. Our guides draw on the method in the book and our work with clients.