Operations and adoption
Getting your team to actually use the system
Adoption is an operations problem, not a software problem
Context
Plenty of automation projects are technically finished and operationally dead: the workflow runs, but the team quietly keeps doing it the old way.
Routing around a system is rational when the system makes an individual's day harder, even if it makes the business better off.
Adoption is won or lost in the first fortnight after go-live — before the workarounds harden into habit.
What changed with AI systems
AI systems improve with use — corrections, examples and edge cases feed them — so low adoption now also means a system that stops getting better.
The gap between a demo and daily reality is wider with AI: trust has to be earned per workflow, not granted per project.
Teams have seen tools come and go; the default assumption is that this one is temporary too.
How to approach this in your organisation
- 01Involve the people who run the process before the build, not at the training session.
- 02Retire the old path deliberately — running both indefinitely guarantees the old one wins.
- 03Make the first fortnight easy to get help in: a named owner, fast fixes, visible responses to feedback.
- 04Show the team what the system saved them, in their terms, not the project's.
- 05Fold their corrections into the system quickly enough that reporting a problem feels worthwhile.
Key metrics
- Daily active use by the people the workflow was built for.
- Items processed through the system versus around it.
- Feedback items raised, and time to visibly act on them.
- Workarounds observed a month after go-live.
Risks to consider
- Declaring victory at go-live and disbanding the support around it.
- Training that demonstrates the happy path and ignores the messy Tuesday afternoon reality.
- Leaving the old process available 'just in case', indefinitely.
- Treating quiet non-use as acceptance instead of as feedback.
