How to get people to actually adopt AI

The uncomfortable truth

Most AI projects that fail in production don't fail on model accuracy. They fail on adoption. Users don't trust the model, don't understand it, or quietly work around it. You can ship something that works and still watch it die from disuse.

A worked example

Picture a claims team given an AI tool that drafts a summary of each case before a handler reviews it. The model is accurate — reviewers rarely need to correct the facts. Usage still collapses within weeks. Why? The handler's job was never "write a summary". It was "make a decision and be able to defend it". The draft summary sits above their existing workflow rather than inside it, so they read the case file as before, write their own notes as before, and treat the AI draft as an extra document to check rather than trust. Nothing about their day changed except one more screen to open.

The fix wasn't a better model. It was redesigning the workflow: the AI draft became the decision record itself, with the handler editing it directly and their edits logged as the audit trail. The task changed from "write a summary" to "correct a summary", which is faster and which people will actually do. Usage went from a novelty to the default within a month, not because the model improved, but because the work around it did.

What actually drives adoption

• Involving users early. People adopt what they helped design. If the first time a handler sees the tool is at launch, you've already lost the argument.
• Explaining, not just deploying. Users need to know what the model does, roughly how confident it is, and how to override it. A model that can't be argued with won't be trusted.
• Redesigning the work, not just adding a tool. If AI drafts a report but the human still writes it from scratch, nothing changes. The task itself has to shrink.
• Training, more than once. A single onboarding email is not training. People forget, roles change, and edge cases only show up after a few weeks of real use.
• Manager buy-in. Line managers set the tone. If a manager treats the tool as optional or joke-worthy, their team will too, regardless of what leadership says.

Trust and the override

Every AI tool needs a visible, low-friction way to say "no, that's wrong". Not a support ticket — a button or a field, right there, that lets the user correct the output and move on. If overriding the model is harder than ignoring it, people will ignore it. The override also does something else useful: it's data. Track what gets overridden and why, and you have a running signal of where the model is weak and where the workflow still doesn't fit.

What an adoption plan actually contains

A technical plan says how the system works. An adoption plan says how people will actually use it, and it needs the same rigour:

1. A named champion in each team, not a project sponsor three layers up.
2. A training schedule with at least one refresh session after go-live, not just induction.
3. Usage metrics defined before launch — not just logins, but whether output is acted on or copy-pasted elsewhere and redone.
4. A stall response — what you'll do, concretely, if usage is flat after month two. Re-training, workflow changes, or stopping.
5. Override tracking — a mechanism to see what users correct and how often.

Pitfalls to watch for

• Usage dashboards flat after month two — the honeymoon period ending with nothing to replace it.
• Users adding manual steps to "double-check" the model, which means the override wasn't good enough or the trust never formed.
• Model output copy-pasted into a different system rather than acted on directly, meaning the tool didn't touch the real workflow.
• Silence from teams who "already have their own way" — often the teams with the most to gain and the least appetite to change.
• Treating adoption as a launch-week problem rather than an ongoing one. Adoption decays; it doesn't hold once achieved.

Next steps

Before you build anything, write down who will use the tool, what their job actually is today, and what specifically would change about their day. If you can't answer that in a sentence, the workflow isn't redesigned yet — you've just added a feature. Then put a number on usage you'll check at 30, 60 and 90 days, and decide now, not later, what you'll do if it's flat.

Where Florence helps

Florence's project briefs include an adoption plan alongside the technical plan by default — champion, training cadence, usage metrics and a stall response, sitting next to the build spec rather than bolted on afterwards. It won't write your override logic or run your training sessions, but it forces the adoption questions to be asked at the same point the technical questions are, which is usually the difference between a tool that gets used and one that quietly gets worked around.