Most AI change programs are planned as communications and training: announce the tool, run the sessions, publish the guide, track the logins. Then the logins fall. The reason is rarely that people did not understand the tool. Their work did not change around it, so the old way stayed easier. Change the work, and adoption takes care of most of itself.
Employees resist bad fit more than they resist AI
The evidence that employees reject AI is weaker than it looks. In many companies the same people who ignore an official tool use a general-purpose assistant on their own, to draft, summarize and search, with no rollout plan and no training session. They adopt it because it saves time on the task in front of them, and they drop the official tool because it does not. What they ask in return is usually modest: keep the data safe, and show that the result is measurable.
People already use AI when it helps them. What they resist is a company tool that adds a step, sits outside the screen they work in, or handles the difficult case badly and leaves them to clean up. Resistance is real, but it is usually specific: to the extra click, the second window, the case the tool gets wrong in front of a customer. Read that way, resistance is a verdict on fit more than a fear of AI, and fit is something the design controls.
Most of the effort belongs in people and processes
BCG's 2024 research on AI value put a ratio on this. It found that around 70% of the challenges companies face with AI stem "from people- and process-related issues, 20% attributed to technology problems," and only 10% from the algorithms. The companies it classed as AI leaders follow a matching rule, putting "10% of their resources into algorithms, 20% into technology and data, and 70% in people and processes."
Most AI budgets run the other way. The model and the platform get the money and the attention; the process, the roles and the habits get a training budget at the end. That is the wrong order for any operation, and it is a common reason good systems sit unused. For a COO, the practical translation is a budget line: if redesigning the process, the roles and the targets is not funded inside the program, the program is planning to train people for a way of working that does not exist yet. The AI implementation guide gives that redesign its own step, before any engineering starts.
Training-led and redesign-led change produce different results
| Dimension | Training-led rollout | Redesign-led change |
|---|---|---|
| Starting point | The tool is ready; tell people about it | The process is redesigned with the people who run it |
| Where the AI sits | A separate tool or tab | Inside the systems and queues people already use |
| Roles | Unchanged; AI is an optional extra | Rewritten around what the system does and what people decide |
| Exceptions | Left to individuals to notice | Routed to named people with context and a target |
| Targets | Old targets, plus a usage goal | Targets that reflect the new flow of work |
| Measure of success | Logins and training completion | Share of work flowing through the new process, rework, bypass rate |
| What happens under pressure | People fall back to the old way | The old way no longer exists |
The last row is the one that matters. When a queue spikes, people do whatever is fastest. If the old process is still there, they will use it, and no training session will stop them.
Redesign the roles around the exceptions
An AI system that handles routine cases changes every role near it. Consider an agent who used to clear dozens of simple tickets a day and now handles a smaller number of hard ones, each arriving with the account history already gathered. A team lead who used to balance workloads now watches the exception queue and the quality of the AI's decisions. A process owner who used to approve policy changes once a quarter now adjusts rules as patterns appear in the exceptions.
Those are different jobs, with different skills and different measures. Writing them down, agreeing them with the people involved and changing the targets to match is the core of AI change management. The design discipline behind it is process redesign, and its bolder ancestor, business process reengineering, holds a lesson most AI programs relearn: a new system dropped into old roles and old targets gets bent to fit them. The person's role on the exceptions is described in human in the loop.
The people who do the work should shape the redesign
Adoption that lasts is driven from the front lines, not announced from the top, and that starts long before launch. The people who handle the process today know which cases are hard, which rules are unwritten and which screens they work around. Put them in the room when the process is mapped and redesigned, and two things happen: the design gets better, and the people who must use it have already shaped it.
This also changes what training is for. It stops being persuasion and becomes practice on a process people helped build.
Measure adoption by how the work flows
Logins tell you who opened the tool. They do not tell you whether the work changed. Better measures:
- the share of cases that run end to end through the new process;
- how often people bypass the system or redo its work;
- the quality of exception hand-offs, as judged by the people receiving them;
- whether the team's targets are being met under the new design.
If the bypass rate stays high, the problem is the design, and the fix is another round of redesign with the people who are bypassing it. The same principle drives the challenges of AI implementation: adoption follows how the system treats the hard cases.
Manthle's engineers build each system around the process and the people who run it, as set out under custom AI solutions, and run it with that team after go-live. The months after launch are where most change programs lose their attention, and they are where adoption is decided.