MODULE 6 · LESSON 3
Free — no login requiredSign in to track progress, save quiz attempts and enrol in the full course.
Sign in to track progress / enrolEarning Adoption
Module 4 showed adoption swinging the benefit by a factor of several — more than any accuracy improvement available. This lesson is about earning it.
Six causes of low adoption
Each has a fix, none is technical, and all are cheaper to address before launch:
The fourth is the most under-appreciated. If a support agent's effort produces a saving that accrues to the operations budget while their own handling time target is unchanged, they have been given work and no benefit. Adoption problems that look like resistance are frequently incentive problems.
Make the good path the easy path
A principle from ordinary product design that applies exactly here: people take the path of least resistance, and your system must be it.
- Default, do not ask. A pre-filled category the user can change beats an empty field with a suggestion beside it.
- One click to accept. If accepting a correct suggestion takes three clicks and typing it manually takes four, you have saved almost nothing.
- Make disagreeing easy too. A one-click override with an optional reason. Cheap disagreement produces the feedback data; expensive disagreement produces silent non-use.
- Never make it an extra window. Anything requiring a separate application will be used for a fortnight.
Building trust deliberately
Trust is a deliverable, and it is built with four specific things:
Show the reasoning, even approximately. "Routed to Billing because it mentions invoice, refund and account number." Users do not need the mathematics; they need something to agree or disagree with. A bare answer invites rejection.
Be honest about performance, including failures. Publish the actual numbers to the people using it. Teams tolerate a system that is right 88% of the time when they know it is 88%. They do not tolerate one presented as reliable that they catch being wrong.
Involve them in setting the threshold. Let the team decide where the confidence cut-off sits between automation and review. They will usually choose more conservatively than you would, and they will own the result.
State the accountability position. This is the question people most want answered and least often ask aloud: if I follow the system's suggestion and it turns out wrong, is that on me? Answer it explicitly and in writing. An unanswered question is answered pessimistically.
The job question
Somebody will wonder whether this is about reducing headcount. Sometimes it is.
Say what is true, as early as you can. If the intention is redeployment, say what to and by when. If the volume is expected to grow and this absorbs it, say so — that is a genuinely reassuring answer and it is often the real one. If headcount will fall, saying so early is better than the alternative: reassurance that later proves false destroys your credibility for every subsequent change, and people will remember it for years.
If you genuinely do not know, say that, and say when you will.
Two practical notes. The people who understand the process best are the ones whose knowledge you need to build it well, and they will not help someone they believe is engineering their redundancy without saying so. And the exception path is a real role — those are the hard cases requiring judgement — so if you describe it as a demotion, it becomes one; if you grade and title it accordingly, it does not.
Two teams in the same company deployed comparable classification systems.
Team A announced at a town hall that AI was being introduced to improve efficiency. The system went live in a new web application. Staff were sent a link and a two-page guide. Accuracy was around 89%. Within six weeks usage had fallen to a handful of people. The project was recorded as a technology failure.
Team B did five things differently, none of them expensive:
- Ran two weeks of shadow mode and showed the team the results first — including the categories it handled badly. The team's reaction was "that's the same one we always argue about", which built more credibility than any accuracy figure.
- Put the suggestion inside the existing queue tool as a pre-filled field, with one click to change it.
- Let the team choose the confidence threshold. They picked a more conservative level than the project had planned, and adoption was higher as a result, so total automated volume was greater.
- Published a weekly accuracy number on the team board, including bad weeks.
- Wrote one sentence and circulated it: if you accept a suggestion in good faith and it is wrong, that is on the system and not on you — tell us so we can fix it.
Team B reached roughly 90% usage and stayed there. Same technology, same company, same approximate accuracy.
The difference cost about a fortnight of a manager's attention and no engineering. It is worth noting which of the two projects would have appeared better-run in a status report: Team A launched on schedule with a communications plan, and Team B spent two weeks apparently not launching.
Support agents ignore an accurate classification system. Investigation shows the saving accrues to the operations budget while agents' own handling-time targets are unchanged. What is this?
The six causes of low adoption
Click to flipOutput in the wrong place; slower than the existing habit; early failures unexplained; effort and benefit in different places; accountability unstated; and no route to disagree.
Click to flip backAdoption moves the benefit further than accuracy does, and all six of its common blockers are managerial rather than technical. Put the output where people already work, make accepting a correct suggestion a single click and disagreeing just as cheap, and build trust with approximate reasoning, honest published performance, a team-chosen threshold and a written accountability position. On the job question, say what is true early — reassurance that later proves false costs you every future change.