The Miles a Field Force Never Has to Drive: A Conversation with Dileep Mundakkapatta

Every technician a telecom carrier sends into the field costs money before any actual work starts, because somebody has to drive there. One route is nothing. Tens of thousands of them a day, across a national network, and small mistakes about who goes where pile up into millions of wasted miles and a lot of people sitting home waiting on a service window. An entire category of software now exists to solve this problem, and it isn't small. The field service management market is expected to grow from $5.10 billion in 2025 to $9.17 billion by 2030, at 12.5% a year, largely because doing it by hand stopped working a while back. What's still an open question is how much of the actual decision you hand to a machine.

Mundakkapatta Dileep Kainary has been at this problem for more than 22 years. He's an Application Architect at IBM and a Senior Member of the IEEE. Much of his career has focused on the systems that decide how large telecom operations move people and work across a network. One of those systems became the focus of our conversation: an AI platform he led that changed how one of the biggest field forces in U.S. telecom picks which technician to send where.

We talked with Dileep about what it takes to teach a field operation to make that call in real time, the parts that nearly fell over, and how far he thinks the automation should actually go.

Field dispatch sounds like a scheduling problem. Why is it harder than it looks?

On paper, sure, you're matching technicians to jobs. In practice it's a decision problem, and the inputs never sit still. Where the tech is this minute, what the job actually needs, traffic, what parts are on the truck, whether the last job ran long. A dispatcher can juggle maybe a dozen of those at once and do fine. A national carrier throws far more at you than any one person can keep in their head.

So the whole thing quietly goes sideways. Everyone optimizes for what's in front of them, sends the closest person, and the system as a whole gets worse without anybody deciding it should. The nearest tech wasn't the right skill match, so the job bounces. Two trucks cross the same neighborhood because nobody could see the full board. It never looks like a failure. It looks like miles and overtime, and most operations just file that under the cost of doing business. I think that's a mistake.

You led an AI platform built to solve exactly that. What did it actually do?

The dispatch optimization platform looked at the whole board at once. It pulled live and historical signals together: skills and certifications, real-time location and traffic, fuel, customer history, what the day's workload actually looked like. Instead of asking who's closest, it asked what single assignment, given everything happening right now, ends up best for the customer and for the network. I led the architecture and delivery, working with the dispatch teams, the data scientists, and the business side to turn all that operational mess into decisions the system could make itself.

And the numbers moved. Technician travel dropped by more than 20%. Over the life of the program that came to something like 51 million pounds of CO2 that never went into the air, which was ultimately a consequence of driving fewer miles. Customers waited less, more jobs got fixed on the first visit. I'll be honest, the customer number is the one I care about, but it and the carbon number come out of the same decision, so you get both or you get neither.

Making that call in real time, across a live network, is a serious engineering problem. How did the system actually decide?

Underneath it was a distributed, event-driven setup. Signals came in continuously and the platform reworked assignments as things shifted, instead of on some fixed cycle. We built it as separate services on purpose, so the routing logic and the data ingestion and the models could each get swapped or updated without pulling the whole platform down. That wasn't a nice-to-have. The operation runs around the clock, so you're doing maintenance on a moving car.

What we did back then was decision support, a human still pressed the button. The industry's moving past that now. By the end of 2026, 40% of enterprise applications will include task-specific AI agents, up from under 5% a year earlier. Dispatch is honestly one of the better places to try it, because the decision has clear edges, you find out fast whether you were right, and a bad call shows up as an actual number. The model was never the scary part. Handing it the authority to act, that's where it got interesting, and slow.

What nearly broke it? Where does a system like this go wrong?

Data quality, mostly. An optimization engine is only as good as what you feed it, and field data is messy in ways you don't appreciate until you're standing in it. A status says a tech is free when they're still wrapping up. The traffic feed is ten minutes behind the actual road. A skill code claims someone can do a job they've never been trained on. Feed a confident model bad inputs and it makes a confident bad call, fast, again and again. We spent far more time early on cleaning and reconciling signals than we ever spent on the routing math.

The other thing that nearly sank it was trust, the human kind. These dispatchers had run the board on gut for years, and the moment a system starts telling them they're wrong, they push back, which is fair enough. If the tool overrides someone and won't show its reasoning, they stop using it, or they quietly route around it. So we made it explain itself. Here's the technician it chose. Here's what it gave up to make that choice. People really underrate that part. The algorithm was maybe a fifth of the work. The rest was getting people to trust it, and a lot of good systems die right there in the pilot because nobody planned for it.

You are also a named inventor on a U.S. patent, for an interceptor architecture used in cloud migration. That is a different kind of work from dispatch. What connects the two?

On the surface they look like two different jobs, but they come out of the same instinct. That patent covers an intelligent interceptor architecture, a way to connect modern cloud platforms to old legacy systems without touching the legacy side. You drop a smart layer in the middle and let it handle the translation. Dispatch optimization follows the same architectural pattern. You put a decision layer between messy real-world inputs and the action you take, instead of trying to clean up every input at its source. Most of my career has been some version of that one idea.

What doing both taught me is that the hard part is almost never the clever core. It's the edges. In the interceptor work it was dozens of legacy protocols that each behaved a little differently. In dispatch it was the dirty field data. The real engineering is making one clean design survive contact with a hundred messy special cases, and honestly that's the part I like most. A system that only works when the inputs are perfect isn't finished, it's a demo.

The emissions savings on that project were significant. Is sustainability a driver in this work, or a byproduct?

Byproduct, mostly, and I'd rather say that plainly than dress it up. Nobody green-lit the Dispatch Learning Engine to save the planet. They wanted lower cost and faster service. But efficient routing and lower emissions are the same thing with two different labels on it. Fewer miles is less fuel, that's the whole trick. Tune the operation for time and money and the carbon comes down whether you were aiming at it or not.

Where it gets interesting is the scale. Transportation is the single biggest source of greenhouse gas emissions in the US, about 28% of the total, and a good chunk of that is commercial fleets still making routing decisions that are far less optimized than modern software makes possible. If software can pull double digits out of the miles a national field force drives, and it can, then this is quietly one of the more useful climate levers around, mostly ignored because it never got sold as one.

Where does this go next? What is still unsolved?

The next piece is closing the loop. Right now most of these systems recommend and a person confirms. Where it's headed is systems that decide and act inside guardrails you set, then tell you what they did and why. That's a bigger jump than it sounds, because the question stops being can the model make a good call and turns into how much rope am I willing to give it, and how will I know when to take it back. That boundary is the part I actually want to work on. Chasing one more point of accuracy bores me next to it.

What nobody's really cracked is the weird middle, the cases no training data ever saw. A storm takes out half a city and every route you planned is useless. A crew calls in sick. Some customer situation that fits none of your categories and just needs a person who can improvise. People are still better at those, and any system that pretends otherwise looks brilliant right up until the day it doesn't. So what I'm putting my time into is operations where the machine runs the routine at full speed and kicks the genuinely strange stuff to a human, cleanly, with everything they need to decide. Get that handoff right and the whole automation-versus-judgment fight mostly dissolves. That's the harder version of the problem, and the more honest one.