Field Notes from Field Service: Same Operating System, Different Business

Last week it was an advisor's office. This week, trucks and a dispatch board. Same operating system underneath. The hard part was never the technology. It was getting people to trust it.

Most people think an AI rollout succeeds or fails on the technology. Build a good enough model, wire it to the right data, and adoption takes care of itself. I used to half believe that too. Then I spent a year watching capable systems get installed into real businesses and quietly die, not because the technology was wrong but because nobody on the floor would use it.

Last week Chuck and I wrote up a boutique wealth management firm, where the fix was a coordination layer underneath eleven disconnected tools. This week I want to take you somewhere that could not look more different on the surface: a commercial field service company. Trucks, technicians, a dispatch board, a phone that rings all day with equipment that has stopped working and customers who needed it fixed an hour ago. I am keeping the details composited, as always, so no client recognizes themselves. The pattern is real, and so is the dispatcher I am about to introduce you to.

The reason I am running these two back to back is that the operating system was the same in both. What changed was the floor it ran on. And the field service rollout taught me something the wealth management one did not, because this is where I watched adoption almost kill a project that was technically working fine.

The business is a coordination problem with wheels

A field service company is dispatch. Strip away the trucks and the tools and what you have is a daily coordination problem that never stops moving. Calls come in. Each one has to be sized, prioritized, matched to a technician with the right skills and the right parts on the truck, slotted into a route that already has six other stops on it, and re-juggled every time a job runs long or an emergency jumps the line. One person usually runs that board, holding the whole thing in their head, and the business grows exactly as fast as that one person can coordinate and not one job faster.

The operator I worked with knew this. He could feel the ceiling. His dispatcher, a woman who had run that board for eleven years, was the single best-informed person in the company and also the single biggest constraint on its growth. Every route ran through her memory. When she was out, the whole operation got slower and dumber. He did not have an AI problem. He had the same coordination problem the wealth management firm had, except his lived in one irreplaceable person's head instead of scattered across five systems.

So we built the same thing we always build. A layer that held the context of the whole operation, every job, technician, skill, part, and route, in one place a system could reason over. An agent that proposed the assignments and the routes. The intent written down in advance: which calls it could schedule on its own, which it had to hand to the dispatcher, and the gate that kept anything high-stakes in human hands. On paper it was working in a month. The routes it proposed were as good as hers, then a little better, because it could hold more variables than any person can.

And it almost failed anyway.

The dispatcher did not trust it, and she was right not to

Here is the moment that taught me the real lesson. The system was proposing good routes, and the dispatcher was ignoring them. She would glance at the suggestion, set it aside, and rebuild the day by hand the way she always had. Adoption was zero, and the project was three weeks from being written off as another tool that did not take.

Her skepticism was not the obstacle. It was accurate.

The easy read is that she was resistant, the change-averse veteran protecting her turf. That read is wrong, and believing it is how these rollouts die. She was not being difficult. She did not trust the system, and she had no reason to yet. She had eleven years of judgment about which customers tolerate a late arrival and which one calls the owner directly, which technician you do not send to which site, which "routine" job is actually a two-hour nightmare. The system did not know any of that on day one, and she knew it did not. Her skepticism was not the obstacle. It was accurate.

The mistake teams make here is to treat adoption as a training problem. Run a session, write a manual, tell people to use the new thing. That never survives contact with someone who has real expertise and real accountability, because you are asking them to trade judgment they trust for output they do not. Field technicians and dispatchers do not resist tools that make the job easier. They abandon tools that add a step or ask them to override their own instincts on faith.

Adoption is earned in the moments that compound

What turned it around was not a better model. It was changing how the human and the system met.

We stopped asking her to accept or reject the AI's plan and started letting the AI propose while she stayed in command. Every route came up as a suggestion she could adjust in two seconds, and every time she overrode it, the system recorded what she did and why it mattered. Her override on a touchy account became a rule. Her note that a particular technician owns the hard refrigeration jobs became part of the context the agent reasoned over the next morning. She was not being replaced by the system. She was teaching it, and she could see it getting smarter in her own image week over week.

There is a specific morning when the person stops rebuilding the plan from scratch and starts adjusting the one the system handed them. That morning is the entire rollout.

That is the moment trust flips, and it is a small one. There is a specific morning, three or four weeks in, when the person stops rebuilding the plan from scratch and starts adjusting the one the system handed them. It is quiet. Nobody announces it. But that morning is the entire rollout, because every day after it compounds. The dispatcher who is correcting a good plan instead of building one from nothing has time she never had. She started catching the things only she could catch, instead of spending her whole day on the routing a system could do. The ceiling on the business moved, and it moved because one skeptical expert finally trusted the thing, not because the model got a few points better.

We learned a version of this back in Series 1, writing about distributed systems, that the hard problems are never the individual nodes. They are the coordination and the handoffs between them. A field service company is a distributed system made of people and trucks. The agent was a good node from day one. The project succeeded the moment we got the handoff between the system and the human right, which is the same lesson, in steel-toed boots.

Same system, different floor

This is why I wanted these two pieces side by side. A boutique wealth management firm and a commercial field service company share almost nothing on the surface. Different customers, different stakes, different vocabulary, different everything. And the operating system underneath was the same: hold the context in one place, let the AI propose, gate what matters to a human, measure the outcome, and earn adoption by making the expert more powerful instead of more obsolete.

If the system only worked in one of them, it would not be an operating system. It would be an industry solution dressed up as one. What carries across the two floors is the coordination layer and the discipline around it. What is specific to each business is the content that fills it, the rules the experts in that business already carry. We bring the system and the method. The operator brings the judgment that makes it theirs. They own that layer when we are done, the rules and the context and the record of every decision about what to automate and what to protect. We keep the method and the reference architecture. Both are true.

Founders, adoption is your problem too

If you are building a product instead of running an operation, do not file this under operations and move on. The hardest part of shipping an AI feature is almost never the model. It is whether your users trust it enough to change how they work, and you earn that the exact same way the dispatcher earned it.

Ship the feature that proposes and lets the user stay in command, not the one that acts and asks forgiveness. Make the override easy and make it teach the system. Watch for the moment your power users stop working around your AI and start working through it, because that moment is your real launch, not the day the feature shipped. A feature that is technically excellent and quietly unused is the most common way I see good AI work die, in startups and mid-market operators alike. The model was never the hard part. The trust was.

The model was never the hard part. The trust was.

Next week we land the series. Chuck and I look at what the next three years of this actually hold, what AI-native looks like when it stops being a transformation initiative and becomes just how companies run, and who ends up owning the coordination layer everyone is about to discover they need. It is the piece we have been building toward since the first article.

AI that runs your business. Not the other way around.