Tom Aldridge remembers the launch day clearly. His team at a mid-size insurance brokerage had spent four months implementing an AI-powered document review tool that cut the time to process new client submissions from three days to four hours. They threw a small celebration. Usage was at 94% in week one. By month six, it was at 41%. By month eight, the two most experienced account managers had quietly stopped using it entirely and gone back to their spreadsheets. Tom, the Operations Director who had championed the project, spent three weeks interviewing his team to understand why. "We'd fixed the technology problem," he says. "We had completely ignored the organizational problem."

The Adoption Curve Is Not a Launch Problem

AI adoption follows a predictable pattern in most organizations. There is a launch phase, visible and energized, often supported by executive attention and the pull of novelty. Then comes what researchers in change management call the valley of despair: the initial enthusiasm fades, friction with the new tool accumulates, the workarounds people use multiply, and usage drifts back toward old habits. Most organizations declare success during the launch phase and discover the valley of despair months later, at which point the implementation team has disbanded and the budget has moved on.

Sustaining AI adoption means designing for the valley before it happens. This is not primarily a technology challenge. The technology was built. It works. The challenge is human, and it has two parts that are worth separating. The first is fatigue: enthusiasm is a finite resource, and a tool that required effort to learn keeps requiring effort long after the excitement that funded that effort has gone. The second is resistance, which is rarely stated openly and almost never irrational. People stop using something that was supposed to help them for reasons that make sense from where they sit. The question to answer is what those reasons are, and what organizational conditions make continued use more likely than regression.

Why Adoption Fades: Four Root Causes

Tom's interviews identified the same four root causes that appear consistently in post-implementation reviews across industries. They are worth treating as a checklist, because they fail independently and each has a different remedy. An organization can solve the friction problem completely and still lose adoption to a metrics problem it never examined.

1. Friction without resolution

Every new tool has friction: moments where it does not quite work the way users expect, where the output requires interpretation, where the integration with other systems is imperfect. In the launch phase, users tolerate friction because the tool is new and there is organizational attention on it. After the launch phase, unresolved friction compounds. Users make a mental calculation, consciously or otherwise, about whether the benefit is worth the friction. When the answer tips toward no, they find a workaround, and the workaround is usually easier to sustain than the tool.

Tom's account managers found that the AI document review tool occasionally misclassified a specific type of commercial liability rider. In month one, they flagged it to the implementation team. In months two and three, they compensated by manually checking that category. By month four, they had built a workaround that bypassed the tool for that document type. By month six, the workaround had expanded to adjacent document types simply because it was faster. The tool worked for 80% of documents. That was not the problem. The problem was that the users had concluded it was not worth the cognitive overhead of knowing when to trust it, and a tool you have to think about before trusting is more expensive to use than one you either trust or do not.

The fix. Build a rapid-response feedback loop in the first 90 days. Users need a frictionless way to report problems, and those reports must generate visible, timely action. The visibility matters as much as the action. If users see problems get fixed and can trace the fix back to something they reported, they stay engaged and keep reporting. If reports disappear into a void, they stop reporting and start building workarounds instead, and by the time anyone notices the usage decline, the workaround has become the process.

2. Metrics that reward the old behavior

Behavior follows incentives. If employees are measured on metrics that the old way of working optimizes better than the new AI-assisted way, they will use the old way, and no amount of communication about the organizational benefit will change that. This sounds obvious stated plainly, but it is frequently overlooked, because AI tools are typically deployed into existing workflows without anyone reviewing how the people in those workflows are evaluated.

In Tom's case, account managers were measured partly on client response time, and a quick personal email from an experienced account manager often got a faster client response than a formally processed AI-reviewed submission. The AI made the process better for the company. It did not, in the short term, improve the metric the individual was evaluated on. The account managers were not resisting change. They were responding correctly to the incentives the organization had given them, which is a different problem with a different solution.

The fix. Before deployment, review the incentive structures governing the people who will use the tool. Identify any metric that might reward old behavior over new behavior, and be specific about the mechanism rather than assuming alignment. Then update the measurement systems so they reward AI-assisted process outcomes, not just output speed measured in ways that the old approach can game. This work belongs to the deployment plan, not to a review months later, because by then the pattern of use has already set.

3. Loss of identity and expertise

Tom's two most experienced account managers, the ones who abandoned the tool entirely, expressed a version of the same concern: "The thing I was good at was reading these submissions and catching the issues. The tool does that now. What am I for?"

This is a real and underappreciated adoption barrier, and it is systematically concentrated among the most experienced users, which is exactly where its effect is most damaging. When an AI tool automates a task that a person derived skill identity from, that person has lost something real. They may intellectually understand that the tool is better at that task. They may even agree it is an improvement for the organization. But the task the tool replaced was part of who they were professionally, and adopting the tool requires accepting a version of themselves that differs from the expert they had spent years becoming. Treating that as resistance to change misdiagnoses it entirely.

The fix. Explicitly redefine what expertise means in the AI-assisted workflow. The experienced account manager has not become irrelevant. They are now the person who knows when the AI is wrong, who handles the complex cases the AI flags as uncertain, who provides the judgment layer on top of the AI's pattern recognition. Make that role visible, named, and valued in the way roles actually get valued in your organization, which usually means in job descriptions, in how performance is discussed, and in who gets asked to weigh in on hard cases. Expert reviewers who apply judgment to AI output are doing skilled work, and the organization has to say so.

4. No visible champion after launch

The executive who sponsored the AI initiative has moved on to the next priority. The implementation team has disbanded. The tool is running, but no one is watching it, advocating for it, or amplifying the wins it generates. When a new employee joins, no one explains why the tool matters or how it fits the work. When usage dips, no one notices, because noticing is nobody's job.

The fix. Assign a named business-side champion before launch. Not a technical owner, who has a different job, but someone in the business unit who is accountable for adoption outcomes and holds a 12-month mandate covering usage targets, feedback collection, and win communication. The champion is the person who keeps the tool present in the organization's ongoing conversation about how work gets done. The mandate needs to be explicit and time-bound because an implied responsibility that competes with an operational role reliably loses.

Measuring Sustained Adoption

You cannot sustain what you do not measure, and the measure most organizations reach for is the least informative one available. Usage rate is obvious and incomplete: high usage of a tool that is being used wrongly is not successful adoption, and moderate usage concentrated in exactly the cases the tool handles well may be. Meaningful measurement needs several angles at once, tracked on a schedule rather than sampled at launch.

• Active usage rate: What percentage of eligible users used the tool in the past 30 days? Track this monthly, not just at launch, because the shape of the decline is more useful than any single reading.
• Workflow integration: Is the tool being used as intended in the workflow it was designed for, or only for a subset of cases? What percentage of eligible cases actually go through it? This is the metric that would have caught Tom's expanding workaround months before the usage rate did.
• Override rate: When users receive AI recommendations, what percentage do they override? A very high override rate may indicate the model is underperforming. A very low rate may indicate users are not applying appropriate judgment. Both directions warrant investigation.
• Outcome quality: Are the business outcomes the tool was meant to improve actually improving? Document review time, error rates, customer satisfaction, whatever the original case was built on. If nobody can answer this, the tool has no defence when budgets are reviewed.
• User satisfaction: A quarterly pulse survey assessing perceived usefulness, ease of use, and confidence in outputs. Not a net promoter score, but specific, actionable questions about the tool's value that tell you what to fix.

Launch day is the beginning of the work, not the completion of it. The tool is not adopted when it goes live. It is adopted when the team cannot imagine working the old way.

Creating a Culture of Continuous Improvement

The organizations that sustain AI adoption longest are the ones that treat the deployed tool as the beginning of an improvement cycle rather than the end of a project. They collect user feedback systematically instead of waiting for complaints. They share wins internally in concrete terms, along the lines of "the AI flagged three errors in last month's submissions that the manual process would have missed, and we estimate that saved us $140,000 in rework." They update the tool when performance drifts. They expand use cases once the tool has proved itself within its initial scope, rather than expanding scope first and hoping.

This requires a different relationship between the business and the AI system, one where the tool is understood as a working colleague that gets better with input rather than a finished product that was handed over at a milestone. It requires the business champion, the technical owner, and leadership to maintain engagement past the launch celebration, which is precisely the point at which organizational attention naturally departs. The cultural signal that matters is what happens when someone reports a problem: whether that is treated as useful information or as a complaint about a project that is already closed.

Tom's team turned their adoption decline around with a monthly "tool Tuesday," a 30-minute team meeting where they reviewed the AI tool's outputs from the prior month, discussed the cases where it was right and the cases where it was wrong, and agreed on one improvement they wanted to request. Participation was not mandatory, but it ran consistently at 80-90%. Usage climbed back to 78% within four months and has held there. What made it work was not the meeting itself but what the meeting created: the tool became part of the team's own conversation about their own work, which meant problems surfaced early, expectations stayed calibrated, and the experienced people had a forum in which their judgment about the tool was the valuable contribution. That, more than any technical feature, is what sustains adoption.

Anti-Patterns

• Declaring victory at launch. Week-one usage measures novelty and executive attention, not adoption. Treating it as the success metric guarantees the decline goes unnoticed until it is entrenched.
• Collecting feedback into a void. A reporting channel whose reports produce no visible action is worse than none, because it teaches users the organization is not listening and converts them to workarounds.
• Deploying into unchanged incentives. Rolling out an AI tool without reviewing how its users are measured leaves people correctly optimizing for metrics the old process serves better.
• Reading identity loss as resistance to change. The experienced user who abandons the tool is usually not opposing the technology; they cannot locate themselves in the new workflow, which is a design problem rather than an attitude problem.
• Leaving the tool without a named business owner. A technical owner keeps the system running. Without a business-side champion holding a time-bound mandate, nobody is accountable for whether anyone uses it.
• Measuring usage alone. A single usage number obscures both misuse and partial use, and it is the last metric to move when a workaround is spreading.

Practice Prompts

• Take an AI tool that has been live long enough to be past its launch phase and plot its monthly active usage from launch to now. Identify the month the decline began and what else was happening then.
• For that same tool, calculate what percentage of eligible cases actually go through it and compare that to the usage rate. A large gap indicates a workaround you have not found yet.
• List the metrics by which the tool's users are evaluated, and decide honestly whether the old process or the AI-assisted process performs better against each in the short term.
• Interview the two most experienced people who use, or have stopped using, one of your AI tools. Ask what they used to be good at, and what they are for now.
• Identify the named business-side champion for each AI tool in production. Where there is none, work out who it should be and what a 12-month mandate would contain.
• Design a 30-minute monthly review for one deployed tool: what gets shown, who attends, and what single improvement request comes out of it.

Reflection

Think about a tool in your own working life that you stopped using after an initially enthusiastic start. What was the specific moment it became easier not to use it? Almost everyone can identify one: a piece of friction that was never resolved, a case where it gave the wrong answer, an occasion where using it made you slower in front of someone whose opinion mattered. Every user of every AI tool your organization has deployed has had that same moment, and in most cases nobody asked them about it. Then ask the harder question about your most experienced people. If an AI system now performs the task that made someone the person others came to, has the organization told them what they are for, concretely, in terms of which cases are theirs and which judgment is theirs? Tom's two best account managers left the tool because nobody had answered that question, and the answer existed; it had simply never been said out loud.

Glossary

• Valley of despair: The phase after launch in which initial enthusiasm fades, accumulated friction becomes salient, workarounds multiply, and usage drifts back toward prior habits.
• Expertise displacement: The loss of professional identity experienced when an AI system automates the task from which a person derived their skill reputation. Concentrated among the most experienced users.
• Judgment layer: The human contribution on top of AI pattern recognition: knowing when the model is wrong, handling the cases it flags as uncertain, and applying domain judgment to its output.
• Business-side champion: A named person in the business unit, distinct from the technical owner, accountable for adoption outcomes under an explicit time-bound mandate covering usage targets, feedback collection, and win communication.
• Workflow integration depth: The percentage of eligible cases that actually pass through the tool, which reveals partial use and spreading workarounds that a headline usage rate conceals.
• Override rate: The proportion of AI recommendations users reject or amend. High values may indicate model underperformance; very low values may indicate insufficient human judgment.

Related Lessons

• Change Management & Adoption covers the broader discipline this lesson applies to the specific problem of post-launch decline.
• Addressing Resistance & Building Support goes deeper on the diagnosis of resistance that this lesson treats as one of four root causes.
• Building an AI Change Coalition addresses how to assemble the champions and advocates who keep a deployment visible after launch.
• Measuring Change Success extends the measurement discussion here into the wider set of change outcomes.
• Change Management & Sustainable Transformation takes the same sustainability question up to the level of an entire transformation programme.

Closing

The uncomfortable lesson in Tom's story is that nothing went wrong technically. The tool did what it was built to do. Every element of the failure was organizational: friction that was reported and not fixed, incentives that quietly favoured the old way, experienced people who could not see their place in the new workflow, and an absence of anyone whose job it was to notice any of that happening. All four are addressable, and none is expensive relative to the implementation itself. A feedback loop with visible action in the first 90 days. An incentive review before deployment rather than after. An explicit, named role for the judgment experienced people bring. A business-side champion with a real mandate. A monthly 30-minute session where the team talks about the tool as part of talking about their own work. That is the whole intervention, and it is the difference between an organization that sustains AI adoption and one that keeps relaunching the same tools to shrinking audiences.

Key Takeaways

• The valley of despair is predictable and preventable. Adoption design must plan for the phase after launch excitement fades, and week-one usage measures novelty rather than adoption.
• Unresolved friction drives workarounds. Build a rapid feedback loop in the first 90 days with visible, timely responses to user-reported problems. This is the single highest-leverage early adoption intervention.
• Workarounds start narrow and spread. A bypass invented for one awkward case expands to adjacent cases because it is faster, and workflow integration depth reveals it long before the usage rate does.
• Incentive structures must reward AI-assisted behavior, not legacy behavior. Review how users are measured before deployment and update any metric that would reward reverting to the old process.
• Expertise displacement is a real adoption barrier, particularly among the most experienced users. Explicitly redefine what expertise means in the AI-assisted workflow, naming and valuing the judgment layer humans provide on top of AI pattern recognition.
• A named business-side champion with a 12-month mandate is the organizational infrastructure that keeps the tool visible once executive attention has moved on. A technical owner is not a substitute.
• Measure adoption from several angles, not one. Active usage rate, workflow integration depth, override rate, and outcome quality together give a meaningful picture, with a quarterly satisfaction check alongside.
• Treating the deployed tool as the start of an improvement cycle rather than the end of a project is the cultural difference between organizations that sustain AI adoption and those that keep re-launching the same tools to shrinking audiences.

Frequently Asked Questions

How soon after launch should we expect adoption to decline? There is no fixed timetable, but the pattern is consistent: usage is highest while novelty and executive attention persist, and drifts once both fade. In Tom's case usage ran at 94% in week one, 41% by month six, and the most experienced users had left entirely by month eight. Track monthly from launch, because the shape of the curve tells you when to intervene.

Our usage numbers look fine. Is adoption healthy? Not necessarily. High usage of a tool being used wrongly is not success, and a healthy-looking rate can coexist with a workaround that has quietly removed an entire category of work from the tool. Check workflow integration depth, meaning what percentage of eligible cases actually pass through the tool, and compare it against the usage figure.

What do we do about experienced people who refuse to use it? Start by assuming they are not refusing. Expertise displacement concentrates among the most experienced users precisely because they had the most invested in the task the tool now performs. The remedy is to define, name, and visibly value their new role as the judgment layer: the person who knows when the model is wrong and handles the cases it flags as uncertain.

Is it worth relaunching a tool whose adoption has already collapsed? Only after diagnosis. Relaunching without identifying which of the four root causes applied leaves the same forces in place, and the second launch reaches a smaller and more sceptical audience. Tom's team recovered usage to 78% within four months, but they did it by fixing the underlying conditions and creating a monthly forum, not by re-announcing the tool.