People do not abandon a tool because they forgot how it works. They abandon it because using it costs more attention than not using it. Every extra tab, login and context switch is a tax, and people quietly stop paying taxes they never agreed to. If your team has drifted back to the old way, more training will not bring them back — removing the tax will.
This is the second way AI projects die. The first is having no baseline, which means nobody can prove whether it worked. This one is worse in a way, because the thing actually worked and still got abandoned.
The shape of the failure
It is remarkably consistent.
Weeks one and two after launch, usage is high — people are curious, and someone senior is watching. By week six it has settled to the handful of enthusiasts who would have found the tool themselves. By month four the licence renews automatically and nobody opens it.
Nobody decided this. There was no meeting where the team agreed to stop. It just became easier, on any given Tuesday, to do it the old way.
Why “more training” is the wrong diagnosis
Training is the default explanation because it is the most comfortable one: it implies the tool is fine and the people need topping up. It also has an obvious remedy, which makes it satisfying to propose.
But watch what actually happens on a Tuesday afternoon. Someone has a task in front of them and two routes to finishing it. The old route is in the application already open, uses muscle memory, and has no chance of producing something they will have to check. The new route means remembering the tool exists, opening it, logging in, moving the work across, checking the output, and moving it back.
They know perfectly well how to use it. They are choosing not to, and it is a rational choice given the layout of their day.
The attention tax, itemised
Each of these costs a few seconds and a little willpower. Together they decide whether something gets used.
| Tax | What it looks like | Removed by |
|---|---|---|
| Remembering | The tool only helps if you think of it | Putting it where the work already happens |
| A second place | Another tab, another login, another window | Building inside the existing system |
| Moving the work | Copy out, paste in, copy back | Working on the record in place |
| Checking | No idea whether to trust this output | Showing sources, and a confident default |
| Blame | If it goes wrong, it is my name on it | An approval step people control |
That last one is under-appreciated. If a person is accountable for the result and does not feel in control of the tool, not using it is the safe career choice. Adoption stalls hardest where the stakes are highest, for exactly that reason.
Beside the workflow, or inside it
Nearly every adoption failure comes down to one distinction.
Beside your systems is a separate tool with its own login, half the team never got access, and a tab nobody opens after week three. It demos beautifully, because in a demo somebody has already opened it.
Inside your systems is the CRM that is already open, the inbox, the helpdesk, the spreadsheet the team has used for six years. There is nothing to remember, because the work never leaves the place it already lives.
The second is less impressive to show and is the difference between a tool and a habit. It is also harder to build, which is exactly why so many projects choose the first and call the result an adoption problem.
Measure adoption properly
Training attendance is not adoption. Licences purchased is not adoption. Track these instead, weekly:
- Weekly active users as a share of the people whose work it touches — not of the whole company, which flatters the number.
- The trend, not the level. Week six against week two tells you far more than any single week.
- Actions completed with it versus around it. If the workflow can still be finished the old way, measure how often it is — that ratio is the honest adoption figure.
- Who stopped. Not a percentage: names. Then ask two of them why, without a manager in the room.
Weekly matters. Adoption decays over weeks, so a quarterly review finds out one quarter late, at which point the habit has re-formed and the budget conversation has already happened.
If adoption has already died
The instinct is to relaunch with better training. Do the diagnosis first.
Ask the people who stopped, not the people who champion it. The enthusiasts will tell you it is great. The three people who used it twice and went back will tell you the actual reason in about ninety seconds.
Find the specific friction. It is almost always concrete and small: it needed a login they never got, it produced something they had to reformat, it was in a tab that closed, it got one thing embarrassingly wrong in front of a customer and they never tried again.
Fix where it lives before you fix what it does. Moving a working tool inside the system people already have open recovers more usage than any feature.
Accept when the answer is no. Sometimes the workflow did not need automating and the team was right. Finding that out is worth the money you stop spending on the licence.
Building for adoption from the start
Three things, decided before anything is built:
- Name the system it lives inside, at the point where you pick the workflow. If the honest answer is “its own new interface”, expect to fight for every user.
- Put the people who do the work in the design. Not a stakeholder workshop — the two or three people whose Tuesday afternoon this actually is.
- Agree the approval points. Where a step touches a customer or moves money, the person accountable should be able to see and override what happened. Control is what makes people willing to rely on it.
Adoption is not a phase that happens after the build. It is a property of what you built and where you put it.
This is why adoption sits inside our scope rather than beside it: if the team does not use it, it has not worked, and we count that as our failure rather than theirs. How it works sets out the three phases; how we build covers where things run and who approves what.