Most AI rollouts don't fail because the tech doesn't work. They fail because nobody figured out the change management.

I learned this while leading the AI rollout across our field operations team: 244 people across 25 markets, none of whom signed up for it. They run rental fleets for a living. They are the kind of people who have watched consultants come in with a transformation deck and leave six months later with their bonuses paid. They are not your eager early adopters.

By the time we got to wave five, adoption was high enough that the bigger problem became people asking us when their tool would get the next feature. Here's what I'd tell anyone trying to do the same thing.

The hardest part is trust, not technology.

The technology problem is a known problem. There are model providers. There are vendors. There are competent engineers who can ship a working pipeline. None of that is the hard part.

The hard part is the conversation at the branch where someone says "I tried the new thing, it didn't work for my situation, and now I have to do the old thing on top of it." That conversation, repeated four times, is how a rollout dies. Not in the architecture review. In the parking lot.

Trust is built by showing up to those parking lot conversations. By killing features that aren't working before someone has to escalate them. By making it boringly easy for people to tell you when something's broken without it feeling like a complaint.

Pilot the problem the team already complains about.

Most pilot programs pick the use case that demos well. That's the mistake. You should pick the use case that solves something the team has been bitching about for two years.

Our first wave wasn't the flashiest AI we could build. It was the most annoying piece of repetitive work on the team's plate. The thing that made Tuesday afternoons suck. We took that, we automated it, and we let the time savings be the story. Nobody had to be convinced that getting their Tuesday afternoon back was a good idea.

If the pilot doesn't solve something people already wanted solved, it's a demo. Demos don't roll out.

Stage trust in waves. Don't bulk-onboard.

We ran the rollout in five waves. Each wave was small enough that if something broke, it broke for a contained group. Each wave was big enough that the people in it could feel the work shift.

The reason for waves isn't politeness or caution. It's that every wave teaches you something the previous wave didn't, and you want that learning to compound before the people who are most skeptical of you get their turn.

By wave four, the field managers who would have been my hardest sells were instead the ones forwarding me feature requests. Not because they'd been converted by a deck. Because someone in their network, someone they'd worked with for years, had told them it actually saved time.

Build with one operator in the room.

Every system I shipped had at least one field operations person co-building with me. Not as a stakeholder. As a builder. They wrote the rules, they spotted the edge cases, they told me when a feature was stupid before I shipped it.

This is the single most important thing I learned. The temptation when you're the AI person is to design what's possible. The discipline is to design what's wanted. You only learn the difference by sitting next to someone who does the work and watching them flinch.

Measure adoption, not deployment.

You can deploy to 244 people and have 12 of them actually use it. That is not a successful rollout. That's an expensive group email.

The metric I track is unprompted weekly usage. Not "did they log in once when we trained them," but "did they come back this week without anyone reminding them." If usage is decaying, the tool is failing them, even if the launch metrics looked great.

The other one I track is what I call negative requests: people asking when their team will get access to the tool. That's the leading indicator of an actual rollout. If nobody outside the wave is asking to be in the next one, you don't have momentum, you have a project.

The tool should disappear into the work.

If your people have to "use AI," you've failed. If they "fill out the inspection like always, but it's faster," you've won.

I have stopped telling teams which parts of the workflow are AI-powered. They don't care, and bringing it up usually makes them more nervous, not less. They care that the work is easier than it was last week. The AI is just plumbing.

The last thing.

The reason most AI rollouts fail is that they're owned by people who love AI. The reason this one worked is that it was owned by someone who loved his operations team and was looking for a way to make their week shorter.

Pick the use case that helps the team you actually know. Build it with one of them in the room. Roll it out small enough that you can fix what's broken before it breaks anyone's trust. Measure whether they keep using it when nobody's watching. And let the tool disappear into the work.

That's the whole playbook.