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. Ten years in production is the only honest proof that it works.

This post walks through what that transition looked like for one operation. A leading airline, crew transport, 3-4 dispatchers removed from the rota, 25% ride cost reduction, in production since 2016. Names have been omitted. The numbers have not.

The Operation

A leading airline 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 3,000 per month and growing.

The airline 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 airline 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.

  1. Intake. The flight schedule and crew roster flow in via API from the airline’s systems. No spreadsheet upload, no manual entry.
  2. 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.
  3. Assign. Rides route to internal drivers, contracted fleets, or partner networks based on configurable cost-versus-SLA rules.
  4. 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.
  5. 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 through autonomous dispatch, end to end
  • Since 2016 in continuous production, through schedule overhauls, fleet changes, and regulatory updates
  • Integrated directly with the airline’s flight-schedule and crew-roster systems, so the engine sees the same operational state the airline does

The 25% is the number the CFO cares about. The 3-4 dispatchers is the number that changed the shape of the operation. The “since 2016” is the one 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 25%. Any competent optimization engine can produce a double-digit cost reduction on its first pass against a manual baseline. The interesting number is the ten years.

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, a crew rest rule that changed, a new station added to the network, a shift-structure revision, a vendor contract with new cost rules, faster than an in-house team could have rebuilt them. Every new constraint modeled for this airline 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 the same operations that started in 2016.

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 was running in 2016. 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.

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 adds up to the 25% figure 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 airline in this case study made that cultural shift. It’s a large part of why the deployment is still running a decade later.