The system went live on a Monday. By Thursday, two of the four transaction coordinators had gone back to their spreadsheets.
Not out of defiance. They didn't announce it. They just quietly stopped using the new thing, because the new thing didn't handle the case where the buyer's agent sends the addendum before the seller signs, which happens about a fifth of the time in their market, and there was no way to enter it, so they worked around it, and once you're working around it for one file you may as well work around it for all of them.
Nobody told the owner for six weeks. By then the system was dead, and $28,000 was gone, and everyone had learned that "the AI thing doesn't work here."
The AI thing worked fine. The design was wrong, and it was wrong because the four people who knew the process best were shown the system in a training session, one week before launch.
The training-session fallacy
There is a widespread belief that adoption is a phase. You build the thing, and then you roll it out, and rollout includes training, and training produces adoption.
It doesn't. Training produces awareness. Adoption is produced much, much earlier — during design, by the act of asking people what actually happens and then visibly building what they told you.
When someone sees their own edge case reflected in a system, something changes in how they relate to it. It stops being management's software and becomes the thing we built to handle the addendum problem. That shift is not achievable by any amount of training, and it is worth more than every feature on your roadmap.
What we do in week one, and why it's not technical
Before we write anything, we sit with the people who do the work. Not their manager. Them.
We ask them to do the task while we watch, narrating. We ask about the last time it went wrong. We ask what they do when the normal path doesn't apply. We ask what they've built for themselves to cope. And then we ask the question that produces the most valuable answer of the whole engagement: what would make this worse for you?
That question is a gift, and almost nobody asks it. People will tell you, immediately and precisely, what would make their job harder — because they've been on the receiving end of software that did exactly that, and they remember. Every answer is a design constraint you would otherwise have discovered in production.
The three things people are actually worried about
Under the surface of every adoption problem are the same three fears, and none of them are about the interface.
"Is this a prelude to me being let go?" If you don't answer this out loud, unambiguously, in the first conversation, people will answer it for themselves in the least generous way — and a person who believes a system exists to replace them will not help you build it. They'll be pleasant, they'll attend the meetings, and they will not tell you about the addendum case.
"Am I going to get blamed when it screws up?" People understand that automated systems fail. What they need to know is what happens to them when it does. If the answer is unclear, they'll keep the spreadsheet as insurance — and running two systems in parallel is worse than running either alone.
"Is anyone going to fix it when it's wrong?" The single fastest way to kill adoption is to ship, declare victory, and disappear. The first two weeks after go-live generate a list of small, real, fixable problems. If those get fixed within days, the system becomes theirs. If they sit for a month, everyone reverts, permanently, and you don't get a second chance.
What it looks like when you get it right
The coordinators are in the room during design. They tell you about the addendum case in week one, along with six others you'd never have found. They argue about the confidence threshold — should the system auto-file at 90% or 95%? — and the argument is good, because it means they've understood what the machine is doing and they're taking ownership of where the line sits.
They name it. This sounds trivial and it is not. Teams that name the system use the system.
And when it goes wrong in week three — it will — they report it in an hour instead of routing around it in silence, because they believe someone will fix it, because you fixed the last four things in two days.
The honest cost of this
It's slower. Doing design this way adds a week or two to the front of every project, and there's a real temptation, particularly when an owner is impatient, to compress it.
Don't. A system nobody uses returns exactly zero, and zero divided by any build cost is a very bad ratio. The week you spend sitting with the people who do the work is the cheapest insurance available against the most common failure mode in this entire category.
We use AI and automation to make businesses more human. That has an operational meaning, not just a philosophical one: the people who do the work are the ones who know how the work works, and any system built without them is a guess wearing a confident face.
Ask them first. They already know the answer, and they've been waiting for someone to ask.