Almost every team we've worked with has a graveyard. A meeting-summary tool nobody used after week three. A "central knowledge base" that ended up with 14 stale documents and a search bar that nobody trusted. A sales-coaching assistant that the sales team uninstalled the day after the rollout meeting. A document-drafting copilot that quietly disappeared from the workflow it was meant to inhabit.
The standard explanation is "we didn't train people enough". This is almost always wrong. We've sat in the rooms where the abandoned tool was being demoed, and the team understood it. They asked good questions. They nodded in the right places. And then they didn't use it.
Adoption is not a training problem. It is an interface problem, an incentive problem, and a trust problem — usually all three at once. This is the playbook we use to fix it.
01 · The curveWhat abandonment actually looks like
Before we get to the moves, it's worth being precise about the failure pattern. Across the engagements we've measured, the curve is so consistent we can sketch it from memory.
The drop happens fast. By day seven we are usually below 60% active users; by day fourteen we are below 35%; by day thirty we have stabilised somewhere between 12% and 20% — three or four enthusiasts and an executive sponsor who is still pretending. The retraining sessions in week six don't recover this. Better marketing emails don't recover this. By the time you notice the problem, the team has already mentally categorised the tool as "not for me", and that label is sticky.
The good news is that the same curve, with four specific changes to the rollout, looks completely different. We have rollouts that are sitting at 70% active users at day 60 and climbing. The changes are not training. They are structural.
02 · Three failure modesDiagnosed in the order they bite
Almost every abandonment we've debugged falls into one of three buckets, and they tend to arrive in the same order.
Interface failure is the first to bite, usually inside the first week. The tool requires more steps than the manual alternative. It lives at a separate URL, behind a separate login, in a separate browser tab. It interrupts the user's current workflow rather than fitting into it. The mental cost of switching contexts is higher than the mental cost of just doing the thing manually. Users do not abandon the tool because it doesn't work — they abandon it because remembering to use it is more expensive than the value it provides per use.
Incentive failure is the second, usually visible by week two or three. Nobody is being rewarded for using the tool. Nobody is being held accountable for not using it. The team's existing performance metrics — sales calls made, tickets closed, invoices issued — don't credit the tool's contribution. The boss doesn't ask about it in the weekly meeting. Users do not abandon the tool because it doesn't help — they abandon it because nothing in their environment changes whether they use it or not.
Trust failure is the third, and it's the deepest. The tool produced a wrong answer once, and the user can't tell whether the next answer is also wrong. Or it produced a plausible answer they couldn't verify. Or it answered with confidence in a domain where the user is the expert and could see the cracks. Users do not abandon the tool because it's bad — they abandon it because they cannot estimate when it's bad, and the cost of being burned by it once is too high relative to the cost of doing it themselves.
The mistake almost everyone makes is thinking these are alternative explanations, only one of which applies. They are sequential. Fix one and you bump into the next. The four moves below address all three at once.
03 · Move 1 · EmbedPut the tool inside an existing workflow, not next to it
The single highest-leverage onboarding decision is where the tool lives. If it lives at a new URL, behind a new login, requiring a new tab, you have already lost most of your users.
The fix is to embed the tool's value at the moment it's needed, inside the surface the user is already looking at. A meeting-summary tool that arrives as a Slack DM thirty seconds after the call ends is used. A meeting-summary tool that requires the user to remember to open a portal and find the right meeting is not. A sales-quote drafter that appears as a button inside the CRM record the salesperson is already on is used. A drafter that opens a separate web app is not.
This is mostly an integration problem, and it's mostly a budgeting problem too. Teams under-spec the integration line because it doesn't feel like the "real" work — the real work is the model and the prompt. We've found the opposite is true. The model and the prompt are 25% of whether the tool gets used. The placement is 60%. (The remaining 15% is the next three moves.)
The cheap version of this move, when full integration isn't on the table, is to push the tool's output to the user proactively rather than asking them to pull it. An auto-generated daily digest at 8:45am of the things the tool noticed overnight will be read. An interface where the user has to remember to log in and ask for a digest will not.
04 · Move 2 · Zero frictionMake the first action zero-friction and zero-stakes
The first time a user encounters the tool — the first time, not the first session — has to be cheap and reversible. Not "easy". Not "intuitive". Cheap. There must be no setup wall. There must be no decision the user worries about getting wrong. There must be a tangible, immediate output that is recognisably useful, and there must be an obvious "ignore this" affordance if the user disagrees.
The classic anti-pattern is the configuration screen on first launch. "Welcome! Choose your tone of voice. Pick a template. Connect a data source. Now let's import your contacts." The user closes the tab. They will not come back. Not because they couldn't have done those things — because they came in with a small amount of attention to spend and you spent all of it on prerequisites.
The fix is to ship a useful first output the moment the user opens the tool, with sensible defaults, and let them adjust later. For an email-drafting assistant: show three drafts of the email currently in the user's draft folder. For a knowledge tool: show the answer to the most common question that team asks. For a meeting summarizer: show the summary of yesterday's meeting that the user already attended. Demonstrate value before asking for input.
The "zero-stakes" half of this matters as much as the "zero-friction" half. The first output the user sees has to be clearly marked as a draft, not a commitment. They are not pressing a button labelled "send". They are not endorsing a position. They are looking at a thing they can take or leave. This dramatically lowers the cost of the first interaction and is what allows the tool to demonstrate value before the user has decided whether to invest in it.
05 · Move 3 · IncentiveTie at least one real incentive to using it
If using the tool is purely optional and the existing metrics are unchanged, the tool loses — not because it's worse, but because the user's environment doesn't reward switching.
— Move 3 · in one sentence
This is the move clients resist most, and it is the most important. If using the tool is purely optional, and the existing performance metrics are unaltered, the tool will lose to whatever the user was doing before. Not because the tool is worse. Because the user's environment doesn't reward switching.
The incentive does not have to be money. It rarely is. The most effective incentives we've seen are:
A change in what gets measured. If the team is measured on, say, response time to inbound leads, and the tool meaningfully helps with response time, then the existing metric is the incentive — but somebody has to draw the line out loud, in a meeting, in front of the team: "we are now expected to respond in under fifteen minutes; here is the tool that makes that possible".
A change in what gets reviewed. If the team's manager looks at three randomly selected examples of the team's work each week, including the tool's contribution, and asks about them, the tool gets used. If the manager doesn't, it doesn't.
A change in who covers the boring part. The most powerful version of this is when the tool genuinely takes over the part of the job the team disliked, and the team is allowed to spend the freed time on the part they like. Salespeople who hated writing follow-ups now have an assistant that drafts them; the salesperson is allowed to spend more time on calls and less time at a keyboard. This is an incentive in disguise — the tool makes the job better, and word spreads.
The negative version of all three — explicit penalties for not using the tool — works in the short term and corrodes trust in the long term. We avoid it.
06 · Move 4 · ReasoningShow the tool's reasoning so users can trust or correct it
Trust failure is the deepest failure mode and the hardest to recover from. Once a user has been burned by a confident wrong answer, they will not trust the next confident right answer either, because they have no way to tell which kind they're looking at.
The fix is to never present an answer without showing the reasoning, the source, and the confidence. This is partly an interface decision and partly an architectural one. Interface: every output the tool produces should have a "why" expandable next to it, showing what data it used, what it concluded, and how confident it is. Architecture: the tool has to actually have those things — citations to specific records, not just a confident assertion; an internal score for how confident it is; an explicit "I don't know" affordance for when it shouldn't answer.
The crucial nuance is that "showing reasoning" does not mean showing every token the model produced. Users do not want to read a chain-of-thought transcript. They want a one-line summary of the rationale, a link to the underlying record, and a clear marker for confidence — typically a colour or a label, not a number. (Numerical confidence scores are widely misinterpreted; categorical labels like "high / medium / verify" are more honest about what the model actually knows.)
The second crucial nuance is the affordance to correct the tool, not just accept or reject. A user who can say "this answer is wrong because of X, learn from this" is a user who has been moved from passive consumer to collaborator. The system should incorporate that feedback visibly — even if it just routes to a queue that a human reviews and uses to adjust the prompt or the retrieval — because invisible feedback is no different from no feedback, and users learn that quickly.
07 · What we avoidTwo adoption tactics that don't work
There are two adoption tactics that are popular and that we now actively avoid.
Mandatory training sessions are not adoption. They are an event. The decision to use the tool is made later, in the user's normal workflow, when the training has already faded. We still do training when clients ask for it — but we treat it as marketing, not as the thing that produces adoption. The thing that produces adoption is the four moves above, every one of which has to be in place before the training session, not after.
Gamification — points, badges, leaderboards — does not work for AI tools. It works for consumer products with a habit loop. It does not work for a workplace tool that is supposed to make work better. Gamification of an AI tool reads as condescending and produces a brief spike in engagement followed by a steeper-than-normal cliff. We have tried it. It backfired. We don't recommend it.
08 · DiagnosticWhere is your current tool failing?
If you have a tool that's been adopted thinly and you want to know which failure mode is biting, the question to ask is not "do people like it" — they will tell you they like it whether they use it or not. The question is "what would happen tomorrow if it disappeared".
If the answer is "honestly, not much", you have an interface failure. The tool isn't woven into anything. Move 1 and Move 2.
If the answer is "we'd be slower, but nobody would push back", you have an incentive failure. The tool helps but nothing in the user's day depends on it. Move 3.
If the answer is "we'd be relieved", you have a trust failure. The tool is making people nervous about its own outputs. Move 4 — and possibly a re-evaluation of whether the underlying task was the right one to automate at all.
The four moves are recoverable if you've already shipped. They are dramatically cheaper if you build them in from the start. We treat all four as mandatory before we agree to call a rollout finished. If any one of them isn't in place, we don't ship — we restructure scope until it is.
The graveyard exists because adoption was always treated as the last problem, after the model worked and the integration worked. It is the first problem. The model and the integration only matter if the tool is used.
Real case studies, every other Tuesday.
Subscribe to The SMB Automation Brief — one anonymised engagement with real numbers, one common mistake we're seeing this fortnight, one tool worth knowing about. 8,400 operators reading.