Most conversations about dispatch automation argue over features. The more useful conversation is about what actually happens when an operation stops using human dispatchers and starts letting an engine decide.
Most “dispatch automation” replaces spreadsheets with a nicer UI and calls it a day. Replacing a dispatcher means the system handles the shift swap, the late flight, and the 3 a.m. reroute without paging anyone. A decade in production is the only honest proof that it works.
This post walks through what that transition looked like for one operation. An airline customer. Crew transport. Dispatchers removed from the rota, a double-digit cost cut, and a deployment that has been running ever since its first year. Names have been omitted. The airline crew transport case study covers the same deployment in data-driven form, and is the public record for the first-deployment year.
The Operation
The customer needed ground transport for flight crews moving between the airport, crew hotels, and crew residences across a country-sized service area. The work ran 24 hours a day, built against a live flight schedule that changed intraday, with cabin and cockpit crews arriving and departing on different rhythms.
When we started, 3-4 human dispatchers ran the operation. Spreadsheets for the shift plan. A phone on each ear. A wall with flight arrivals and departures. The day shift handed off to the night shift and the night shift handed back a worse state than it received. Ride volume was on the order of a few thousand per month and growing.
The customer didn’t want a better dispatcher console. It wanted to stop dispatching by hand.
Why Manual Dispatching Fails at This Shape of Problem
Crew transport looks simple from the outside. Pick up a pilot, drive to the airport. The work is not the simple case. The work is the density of constraints the dispatcher has to hold in their head simultaneously.
- Crew rest and duty-time regulations the customer cannot violate without a rostering headache
- Flight delays that ripple through the next six pickups
- Home-address pickups for some crew, hotel pickups for others, and crews that switch between the two on consecutive days
- Vehicle capacity, driver working hours, and shift-break rules for the drivers themselves
- Split flights, crew swaps, and standby crews that appear on the schedule hours before operating
- Cost ceilings per ride, preferred vendors, and exclusion lists for specific routes
A good human dispatcher can juggle roughly twenty simultaneous constraints on a good day. Add a flight delay and the juggle gets harder. Stack two delays on top of a sick-day backfill and the dispatcher picks a plan that satisfies the loudest constraint and quietly violates a quieter one. That’s the failure mode. Manual dispatch doesn’t break visibly. It just gets more expensive the busier the schedule gets, because the dispatcher is optimizing for the constraint in front of them, not the operation as a whole.
Manual dispatch also scales linearly with headcount. Double the rides and you double the dispatchers. That math ends the same way every time.
What Autonomous Dispatch Actually Replaces
An autonomous dispatcher is not a planner that a human then executes. It covers the full loop, from the moment an order arrives to the moment it’s delivered, with no human in the middle on the standard case.
- Intake. The flight schedule and crew roster flow in via API from the customer’s systems. No spreadsheet upload, no manual entry.
- Optimize. The VRPTW engine builds a rolling plan across every open crew movement, respecting all the constraints listed above at once, and re-solves whenever an input changes.
- Assign. Rides route to internal drivers, contracted fleets, or partner networks on rule-driven cost-vs-SLA logic.
- Notify. Drivers get the turn-by-turn. Crew members get the pickup confirmation and the driver’s contact. Operations managers get the exceptions that actually need a human.
- Re-optimize on exception. A flight slips 40 minutes. A driver calls in sick. A crew swap drops an hour before operating. The engine absorbs the change and reshapes the affected rides without a human re-planning anything.
The first four stages are table stakes for any serious dispatch platform. The fifth is the one that separates a planning tool from a replacement for dispatchers. For a broader look at how platforms stack up on this distinction, read our dispatch automation platforms comparison.
The Results
- ~25% reduction in ride cost per crew movement, measured against the pre-automation baseline
- 3-4 dispatchers removed from the manual rota, including the full night shift
- ~3,000 rides per month running end-to-end through autonomous dispatch
- A decade of continuous operation across schedule overhauls, fleet changes, and regulatory updates. The first deployment year is documented on the crew transport case study page
- Integrated directly with the customer’s flight-schedule and crew-roster systems, so the engine sees the same operational state the customer does
The ~25% is the number the CFO cares about. The dispatcher removals are the number that changed the shape of the operation. The decade is the number that matters most, and it’s the one the rest of this post is about.
What Buyers Don’t Realize
The interesting number in this case study is not the cost cut. Any competent optimization engine can produce a double-digit cost reduction on its first pass against a manual baseline. The interesting number is the decade.
Most enterprise dispatch deployments get replaced every two to three years, when operational requirements drift faster than the original vendor can absorb them. The reason this one didn’t is that the constraint library kept absorbing new edge cases faster than an in-house team could have rebuilt them. A crew rest rule that changed. A new station added to the network. A shift-structure revision. A vendor contract with new cost rules. Every new constraint modeled for this customer also became available to every other operation on the platform. That is a compounding asset. An in-house build is a depreciating one.
This is the point worth sitting with. Optimization solvers are a commodity. There are open-source ones, licensed ones, and academic ones that will all solve a textbook VRPTW just fine. What an engine does when the problem doesn’t match the textbook is not a commodity. That behavior is accumulated in a constraint library, one vertical at a time, over years. Mycelium has nine verticals and a decade in the library. A new entrant has neither, and there is no shortcut to either one.
Enterprise buyers don’t keep a dispatch engine in production for a decade by accident. The largest deployments on the platform today are operations that started in their first deployment year and have been compounding ever since.
Why the Shape of This Problem Repeats
The case study above is about airline crew transport. The shape of the problem is not.
Grocery delivery from a national chain has the same density, different constraints. Field service for a telecom has it. Corporate employee commute across a metro area has it. Student transport with pick-up windows around bell schedules has it. Any operation where a human dispatcher holds more than about twenty simultaneous constraints in their head is running the same losing game the airline operation was running when we took the account. The specific constraints are different. The math of manual dispatch is the same.
Each of those verticals has its own landing page with the constraint set that applies.
- Crew transport for airlines, shipping, and shift-work fleets
- Corporate commute for employee transport across a metro area
- Last-mile delivery for retail, grocery, and e-commerce
- Field service for technicians, maintenance, and installation crews
When Manual Dispatch Is Still the Right Answer
Autonomous dispatch doesn’t make sense for every operation. Small footprint, fixed schedule, few exceptions, one human can hold the entire state in their head and a platform adds complexity without replacing meaningful work.
Rough cutoff. Under roughly fifty rides per day, a single depot, a fixed recurring schedule, and an exception rate below five percent of rides. Below that threshold, a spreadsheet and a competent coordinator is the correct answer. Above it, and especially as volume scales or exception rate climbs, manual dispatch starts losing money the operator doesn’t see on any single day but that adds up to a 25% gap over a quarter.
What Autonomous Dispatch Requires You to Give Up
The hardest part of this transition is not the integration. It’s the operational culture shift.
You stop second-guessing the engine’s assignments. You stop running the spreadsheet in parallel “just in case.” You stop asking the engine to produce a plan for the dispatcher to approve, and you start letting it dispatch. Operations that treat autonomous dispatch as a suggestion tool capture a fraction of the savings. Operations that let it run capture the full number.
The customer in this case study made that cultural shift. It’s a large part of why the deployment is still running. Specific deployment details available under NDA in a demo conversation.