An AI adoption strategy is a one-page plan that says which work AI will change first, who is accountable for each change, and what evidence decides whether it carries on.
After a readiness assessment, write it in this order: pick one use case per team on volume and reversibility rather than value, name one accountable person for each, spend the first quarter finding your real constraint, and fix a day-90 checkpoint that ends in continue, change or stop. Keep the whole thing to one page.
The first decision does the most damage when it is wrong. The instinct is to start with the highest-value use case, which is nearly always the highest-stakes and the hardest to undo, so the first visible mistake lands on the thing the board was watching and the programme never earns a second quarter. This post is for the COO, transformation lead or founder who is holding a readiness result and a budget, and would rather not produce a 40-slide deck that nobody executes.
What do you need in place before you write the strategy?
You need three things: a readiness result that names a blocker, a budget with an owner, and a list of work your teams already do repeatedly. Gathering them takes a few days, mostly spent chasing whoever holds the budget.
The readiness result matters most. Without one, you are choosing a use case on a theory about what is holding the business back, and what an AI readiness assessment measures is exactly the test of that theory. Innovate UK's BridgeAI Adoption Stages Framework uses the same order: the strategy stage, which asks whether AI suits the business challenge, the goals and the budget, comes before data, build and implementation.
Step 1: How do you choose the first AI use case?
Choose the first use case on volume and reversibility rather than value: work your team does often, where a mistake is cheap and a person already reviews the output before it goes anywhere.
Value is the wrong first filter because the highest-value work is usually the highest-stakes, and stakes decide how much damage a first failure does. Amazon's 2016 letter to shareholders makes the general point: many decisions are reversible, two-way doors, and those can use a "light-weight process". Treat your first use case as one of those.
Score every candidate on three questions:
Volume. Is the work done many times a week, so you collect evidence in weeks rather than months?
Reversibility. Is an error caught before it reaches a customer, a regulator or the ledger?
Existing review. Does someone already check the output as part of the job?
Good first picks look like first drafts of replies to routine supplier queries in Microsoft Copilot, meeting summaries with action lists, or a first pass at sorting invoice queries for the finance team. Poor first picks issue a decision about a person, put a number in front of a client, or produce output nobody reads before it is used.
Where the work touches decisions about individuals, the ICO's guidance on automated decision-making and profiling turns on whether a decision involves meaningful human involvement. So the review step has to be a real check with time allocated to it, not a name on a rota.
Allow about a week: one session with team leads to list candidates, one to score them. What goes wrong is that the board's favourite idea wins by default. Score it like everything else, including the one the chief executive mentioned at a conference.
Step 2: How many AI use cases should you run at once?
Run one use case per team, in one or two teams, and no more in the first quarter. Beyond that the plan is a wish list.
A team can only change how it works in one place at a time, and the review load stays visible when there is a single use case to review. A company-wide shortlist of five means five owners, five sets of evidence and no way to tell which of them moved anything. Two teams each running one use case give you two small tests in different conditions, which tells you more than one large test in a single department.
Deciding which teams go first takes an afternoon. Pick the ones with a willing lead and a repeatable task, not the ones with the loudest enthusiasm. A firm with a dozen staff needs one use case in total, and that is fine.
Step 3: Who should be accountable for AI adoption?
One named person per use case should be accountable, not a steering group.
Write a name on the page, not a function or a committee. A steering group can approve a plan, and nobody on it will be asked on day 60 why nothing has moved. The accountable person is usually the team lead whose work is changing, because they control how the work gets done. Pair them with a sponsor at COO or director level who can clear blockers and answer to the board.
If nobody can be named, you have an intention rather than a strategy, so stop and fix that first. Naming the person should take one conversation; if it takes more than a week, treat that delay as your first finding. The failure to watch for is a name with no time attached. Give the owner a protected weekly slot to read the output, because accountability without hours is decoration.
Step 4: What is the first quarter actually for?
The first quarter is for finding your real constraint, not for banking hours saved.
A constraint is whatever stops the use case working at the speed you hoped: permissions on the data, a tool nobody approved, a review step that takes longer than the task, or a manager who does not trust the output. It is rarely the model. You cannot see it in a slide deck. You find it by running one real piece of work and watching where it stalls.
Plan for learning, not savings, because most organisations cannot yet show the numbers anyway: ivee's research with 500 UK AI decision makers, surveyed in August 2026, found that 4% can prove the ROI of their organisation's AI spend and 96% cannot show the numbers. A plan that promises savings in the first quarter is setting up its own failure, because the evidence to confirm them does not exist yet.
Take the baseline in the first two weeks, before anything changes, using one of the approaches in how to measure AI adoption without a number you cannot defend. Without a before, there is no after, and the checkpoint turns into an argument about how people feel. The usual failure here is banking hours: the team reports optimistic savings, and the quarter ends with a number nobody can trace.
Step 5: What decides continue, change or stop?
A checkpoint at day 90 decides it, against criteria written on day one: continue, change or stop.
Continue when a sample of reviewed output held up, the constraint you found is fixable, and the owner wants to widen the scope.
Change when the use case is sound but a named constraint blocked it. Fix that one thing and run another short cycle.
Stop when the work is not suited to AI, and write down why so the lesson outlives the programme.
The evidence is four items: the baseline, a sample of output with the corrections the reviewer made, the list of constraints, and the owner's recommendation. Collecting it takes a few days, and the review itself is one meeting with the owner and the sponsor.
Write the stop condition before you start. Otherwise nobody wants to be the person who calls it, and the pilot extends by default. If the answer is continue, that is the moment to put a number on the case for widening it. A free calculator that turns hours saved per person per week, team size and industry into an annual figure takes about a minute, and it works best fed with the measured hours from your baseline rather than a guess.
Step 6: How do you write an AI adoption strategy on one page?
Write it as six lines on one page, in plain words, so the owner of each use case can recite it.
The use case and the team. One sentence naming the work.
The accountable person. By name, plus the sponsor.
The baseline. Which measure, taken when, and by whom.
What the quarter is for. The constraint you expect to test.
The checkpoint. The date, the evidence and the stop condition.
What you are not doing this quarter. The use cases you ruled out, and why.
The sixth line does the most work. It is where the board's favourite idea waits, with a date on it, instead of being ignored. The failure to avoid is the page growing into a deck. Anything that does not change what a team does on Monday goes in an appendix, and the appendix stays short.
How long does this take, and what does it cost?
Allow two weeks to write the plan, most of it waiting for people to answer, then 90 days to run it.
The cost is mostly time: the owner's weekly slot, the reviewer's time on the output, and whatever licences the use case needs, such as a Microsoft 365 Copilot seat, a ChatGPT Enterprise seat or a Claude plan you may already hold. ivee sells training, and training is one input to a plan like this. It helps when the constraint turns out to be skill. It does nothing when the constraint is permissions or a reviewer with no time, and only the first quarter can tell you which you have.
What usually goes wrong with an AI adoption strategy?
The most common failure is treating the document as the adoption. A strategy document is not adoption, and the gap between the two is where most programmes die: the plan is approved, the page circulates, and nobody changes how Tuesday's work gets done.
Starting with the biggest prize. The first failure lands somewhere visible and the programme loses its second quarter.
No named owner. Without one, there is no strategy, only an intention.
Promising savings in quarter one. The first quarter usually returns learning, and a plan built on savings has written its own failure.
No stop condition. A pilot nobody can end becomes a permanent line in the budget.
The sequencing rule has limits. If your highest-value use case is also low-stakes and easy to undo, such as internal analysis nobody outside the team sees, start there. The rule is about reversibility, and value only breaks the tie.
The plan also has a limit that no page can fix: it tells you where to look, and it cannot make a team change how it works. That part takes someone accountable and a quarter of real work. ivee's AI services page sets out what a team programme covers and where training fits in a plan like this.
