Every AI project has two launches. The first is the day the system works. The second is the day people stop doing the job the old way. Most projects celebrate the first and never quite reach the second, and the return on the whole investment lives in the gap between them.
Budgets, timelines and demos are often organised around the day a system works, as if adoption follows automatically. It does not: adoption needs its own owner and measure, and determines whether the investment pays.
The demo is not the deliverable
A demo proves that something can happen. A deliverable is something that does happen, every day, without anyone in the room who built it. The distance between the two is made of small, unglamorous things: the login that was never set up for the receptionist, the edge case that sends a client email to the wrong folder once a week, the manager who still asks for the spreadsheet because that is what the board expects to see.
None of these is a technology problem, and none of them shows up in a demo. They show up in week three, when the novelty has worn off and the people who have to live with the system decide, quietly and reasonably, whether it makes their day easier or harder. If it makes their day harder, even slightly, they route around it. That is not resistance to change. It is a sensible judgement about their own time.
Nobody adopts a system. People adopt the version of their day that the system makes possible.
Why people route around new systems
The old way has one enormous advantage: it is known. Everyone can see where the work is, who is doing it and what done looks like. A new system moves the work somewhere else, and for a while nobody can see it. That period of invisibility is where trust is won or lost. If a lawyer cannot see that the file note was drafted correctly, she will draft it herself. If a clinic owner cannot see that the consultation report went out, he will send it again.
So the practical question is not how to get people to use the system. It is how to make the system's work visible, checkable and, at the start, easy to correct. Show the draft before it is filed. Put the human review step on screen, not in a policy document. Make the first hundred outputs easy to inspect, and let the people who used to do the job be the ones who sign them off. Trust is built in the review queue, not the training session.
Three conditions we look for before we call a system adopted
- 01Someone owns it by name. Not a department, a person, with the authority to change how the workflow runs and the time to look at what it produces each week.
- 02The old way has been retired. Until the spreadsheet is closed and the manual step is removed from the checklist, the new system is an experiment running alongside the real process, and experiments get abandoned.
- 03The number has moved. Hours recovered, documents produced, calls answered. Whatever was agreed at the start is now reported without anyone being asked, and the people doing the work recognise it as true.
When all three hold, the system has crossed the second launch. When any one is missing, it is still a demo with a long runway, however good the technology underneath it.
What this changes about how we work
It means the engagement does not end at go-live. The weeks after launch are planned and paid for as part of the build, not as an optional support extra, because that is when the return is made. It means we measure adoption directly, by looking at whether the old way has actually stopped, rather than by counting logins. And it means the first version is deliberately conservative: fewer features, more visibility, a review step that a sceptical person can trust.
The capability will keep improving on its own. Adoption will not. It must be designed, owned and measured.
