The AI Adoption Framework: Five Drivers, Four Phases, and the Plateau

Most AI deployments fail at adoption rather than technology. The system works, and three months later a third of the intended users are still doing it the old way, because the old way is still available and nobody gave them a reason to stop.

Adoption is a separate programme from delivery, with its own owner, its own budget line, and its own measurement. Organizations that treat it as the tail end of a build get the outcome described above.

The short version

Five drivers determine whether a rollout lands: manager engagement, time to first value, workflow integration, performance signalling and peer modelling. Manager engagement is the largest single one.

Four phases: eight weeks before launch, the first four weeks, weeks four to twenty-four, then month six onward.

Expect a plateau around month nine. It is normal, and it marks the point where voluntary adoption runs out and the work changes.

The five drivers

Manager engagement. A manager decides within roughly three weeks whether their team uses a tool properly, works around it, or waits for it to be forgotten, and the team follows. Managers who have not been prepared default to protecting their team’s throughput, which usually means permitting the old process to continue. Train the manager layer before their teams, not after, and give them something specific to say about what changes.

Time to first value. How long between a person’s first use and the first moment the tool saved them something they noticed. Under a week and adoption largely handles itself in that cohort. Past three weeks, most people stop trying. This is a design constraint on the rollout rather than a training problem: pick the first task for each role so that it is one where the tool is obviously better, even if it is not the highest-value task.

Workflow integration. Whether the tool sits inside the work or beside it. A system that requires opening a second application, in a second tab, with a second login, is competing against a process that requires none of those. Integration beats enthusiasm over any horizon longer than a quarter.

Performance signalling. Whether the organization has said, in a way people believe, that using this is expected rather than encouraged. This does not require mandating anything. It requires that the expectation appears somewhere that carries weight: objectives, review conversations, the standard a manager holds work to.

Peer modelling. People adopt what visibly competent colleagues adopt. This is why champions work and announcements do not, and why the champion has to be someone the team already respects for their domain skill rather than someone who volunteered because they like new tools.

What preparing a manager actually involves

Most manager preparation is the staff training delivered a week early. That teaches the manager to operate the tool and leaves them with nothing to say when someone on their team asks the questions they actually ask. Four things, and ninety minutes is enough for all of them.

What changes in their team’s work, named as specific tasks rather than as capability. A manager who can say “you will stop doing the first pass on these, and you will start checking the output against the standard you already hold” has something to manage. “It will make us more productive” gives them nothing to do on Monday.

What they are expected to do about people who carry on the old way, and when that expectation starts. Managers assume the answer is nothing, and for the first quarter they are usually right, which works fine as long as somebody says so out loud and names the date it changes.

Where the line is: the cases in their function that must not be handled with AI assistance, described in their own language, with a route for anything ambiguous. This is the part managers ask for most often and receive least often.

What to do operationally when the output is wrong. Who they tell, what the team stops doing while it is looked at, and how long they should expect that to take. A manager without an answer here will quietly tell their team to keep the old process running, which is the single most expensive thing an unprepared manager does.

The four phases

Weeks minus eight to zero. Permitted-use policy published. Manager training delivered. Baseline measurement taken, which cannot be done later. Champions identified per function, chosen for domain credibility. First-use task designed per role against the time-to-first-value constraint. Decide explicitly what happens to the old process and when it is withdrawn.

Weeks zero to four. Launch into one function rather than everywhere. Question volume is the health signal here and rising questions are good; silence means people are not using it or not telling you when it misbehaves. Champions visible and available. Managers checking in weekly rather than monthly. Fix the friction reported in the first fortnight immediately, because the first impression sets the ceiling.

Weeks four to twenty-four. The sustaining phase, and the one that gets defunded. Workflow integration work happens here, since the launch version is nearly always bolted alongside the process rather than inside it. Performance signalling starts once enough people have had a fair chance. Quality sampling begins. Withdraw the old process on the date you announced, or admit publicly that you are not going to, because an indefinite parallel path is a decision whether or not anyone makes it.

Month six onward. Scaling to the second function, and the honest checkpoint on whether the first one actually changed. Cross-function work begins here.

The curve, and the plateau

Enterprise AI adoption climbs faster than previous technology waves and plateaus earlier. The steepness comes from consumer familiarity: people arrive already knowing roughly what these tools do, which removes the education phase that slowed earlier rollouts.

The plateau typically appears around month nine. It arrives when everyone who wanted the tool has taken it and everyone who did not has no reason to. Organizations misread it as evidence the system was wrong and cut the programme, which converts a plateau into a decline.

What the plateau actually signals is that the drivers you have been relying on, which are peer modelling and enthusiasm, are exhausted. The remaining population responds to workflow integration and performance signalling, both of which are more expensive and neither of which is a communications exercise. Budget for that phase at the outset or you will be asking for money at exactly the moment the numbers look worst.

The other thing that widens after month nine is the gap between organizations. Two companies that deployed the same tool on the same date diverge sharply, and the divergence tracks programme management rather than technology choice.

Cross-function adoption

Function-by-function rollout is correct and it produces silos by default. Three patterns break them, and none is expensive.

Showcases. A regular, short session where one function demonstrates something working to the others, including what did not work. Fifteen minutes of a real screen beats a deck. The value is less inspiration than the discovery that two functions are solving the same problem separately.

Champion exchange. Champions from one function sitting with another for a day. The transferable asset is rarely the use case; it is knowing which failure modes to expect and what a bad output looks like before it causes a problem.

Shared workflow integration. Where two functions touch the same process, integrate once. This is the pattern with the most compounding value and the most coordination cost, and it needs an owner above both functions or it does not happen.

The constraint on all three is champion bandwidth. Champions are, by selection, people who are good at their actual job, and organizations quietly convert them into full-time evangelists until they burn out or go back to their day job. Cap it, name the cap, and backfill the time.

What to measure

Share of the intended population that has stopped using the old process entirely. The single most informative number and the least flattering. It distinguishes a transformation from a portfolio of pilots.

New-path usage against old-path usage, by function. Tells you about adoption independently of whether the system is any good.

Quality of AI-assisted work against the standard the function already held, sampled at a defined rate. Catches the failure mode of faster and worse.

Time to first value for new users, tracked as a cohort. When this number rises, something in onboarding has broken.

Question and escalation volume, where silence in the first two months is a warning.

Licence counts measure procurement. Training completion measures attendance. Neither belongs in an adoption report, and both appear in most of them.

The three failures

Top-down rollout without manager engagement. An executive announcement, a training module, and a manager layer that heard about it at the same time as their team. The most common shape and the most predictable outcome.

Tool-first. The tool was bought, then a use case was found for it. Adoption programmes cannot rescue this, because the people being asked to change their work can tell the difference between a tool that solves their problem and one that arrived looking for one.

Training as the strategy. Training is one input among five. Organizations that respond to weak adoption by commissioning more training are treating the driver that is easiest to buy rather than the one that is binding, which is usually workflow integration or an unprepared manager layer. Check both of those before signing another content order.

Counter: shouldn’t adoption happen on its own?

Partly, and the part that happens on its own is the part you least need help with. Self-directed adoption reaches the people who were going to adopt anyway, in tools they chose themselves, to a standard nobody has defined. That produces capability without permission, uneven quality, and a shadow-tool problem.

The population that requires a programme is the one where the value is: people whose work is governed, whose errors are expensive, and who are correctly cautious about changing a process that currently works.

The economics of the parallel process

Running the old process alongside the new one is the most expensive decision in adoption, and it is almost never made deliberately. It happens because withdrawing the old path feels risky at exactly the moment the new one is least proven.

The cost is not the duplication. It is that a parallel path removes the forcing function. Anyone who finds the new tool slower, confusing or frightening has somewhere to go, and the people who go there are disproportionately the ones whose work carries the most risk and who therefore most needed the new controls.

It also destroys your measurement. Usage figures with a parallel path open tell you about preference rather than capability, so you cannot distinguish a tool problem from a training problem from a manager problem.

The workable position is to announce the withdrawal date at launch, keep it short, and hold it. Where you decide not to hold it, say so publicly and set a new date. An indefinite parallel path is a decision made by silence, and staff read it accurately as the organization not being serious.

The exception is genuinely regulated fallback, where you need the old path available for cases the new system must not handle. That is a designed exception with defined triggers, which is a different thing from leaving the door open.

What adoption looks like at maturity

Three markers, and they take eighteen months at best.

New joiners learn the new process as the process, with no reference to what it replaced. This is the point at which the change has actually landed, and it takes as long as it takes for the population to turn over enough.

Functions propose uses you did not design for. This is the strongest available signal that capability is real rather than compliance-shaped, and it is the point at which the programme starts generating its own pipeline.

Nobody runs adoption campaigns any more. The work has moved into onboarding, tooling and management practice, and the programme structure has dissolved into normal operations. Programmes that still need campaigns at month twenty-four have not achieved adoption, they have achieved a permanent marketing function.

What to do this quarter

If you have not launched: take the baseline and train the managers. Those two, and nothing else, are worth this quarter.

If you launched and adoption is soft: check the time to first value and check whether the old process is still available. In most cases the answer is in one of those two before it is anywhere else.

If you have plateaued around month nine: stop communicating and start integrating. The remaining population is not waiting for another message.

For the wider sequencing this sits inside, see AI strategy for CTOs and CEOs. For the workforce capability layer underneath it, AI literacy and communicating AI to your workforce.