The failure that gets recorded as a technical one
A model performs well, goes live, and six months later the planners still use their spreadsheet. The project is written off as machine learning not working here.
It usually failed for reasons that had nothing to do with the model. It appeared in the wrong place, at the wrong moment, with no explanation, from a project the users first heard about when training was scheduled.
Three conditions for adoption
- It makes their job easier, not harder. A prediction requiring a login to another system is extra work, whatever its accuracy.
- They can see when it is right. Visible accuracy history builds trust faster than any explanation of the method.
- It fits where the decision is made. If the buyer decides on Tuesday morning in a specific screen, that is where the number has to be.
None of these is about the model. All three are about the surrounding design, and they are usually decided late by whoever is available.
Involve the users in defining it
The people who will use the output know things the project does not: which cases are hard, what they already take into account, why the obvious approach failed last time.
Involving them early has two effects. The model is better, because those constraints get built in. And adoption is easier, because it is a tool they helped shape rather than one imposed on them.
It also surfaces the uncomfortable question early: what happens to their role. Avoiding that conversation does not prevent people from having it privately, and quiet resistance is far harder to address than a stated concern.
Never frame it as replacing judgement
Presenting a model as more accurate than the experienced staff currently doing the job is both bad practice and frequently untrue at the individual level. The best planner may well beat the model on the cases they know well.
| Unhelpful framing | Better framing |
|---|---|
| The model decides | The model does the first pass, you handle the exceptions |
| It is more accurate than you | It is consistent across everything, you have context it lacks |
| Trust the number | Here is its track record - judge it yourself |
| This replaces the spreadsheet | This fills in the spreadsheet so you can work on the hard cases |
Make overrides a feature
Staff will override predictions. Design for it rather than fighting it: let them, require a brief reason, and analyse those reasons.
Overrides are among the most valuable data a deployed model produces. Where they consistently improve outcomes, there is information the model does not have and should. Where they consistently make things worse, that is a specific, evidenced coaching conversation rather than a general complaint about resistance. Our piece on why staff override predictions goes further.
A model nobody uses has the same business value as one that was never built.