AI dispatch explained

“AI dispatch” is one of those phrases that can mean anything from a genuinely smart system to a random number generator with good marketing. This post explains exactly what FleetView does in the ~2 seconds between an order being confirmed and a rider’s phone buzzing — no hand-waving.

The problem, stated honestly

Dispatch is an assignment problem under uncertainty. At any moment you have N orders in various states of readiness and M riders in various states of busyness, and you need to decide who takes what — while food is getting cold, customers are watching ETAs, and three more orders are about to land. A human dispatcher with a phone solves this by gut feel and shouting. It works until Friday 8 pm, when it very much does not.

Step 1: Filter — who is even eligible?

Before any scoring, hard constraints eliminate riders: off shift, at delivery capacity, wrong vehicle type for the order (a 20 kg grocery batch does not go on a bicycle), outside the branch’s service area, or shift ending before the delivery could plausibly complete. This step is deterministic and boring, which is exactly what you want from constraints.

Step 2: Score — who is best?

Every eligible rider gets a composite score. The main signals, in rough order of weight:

• Effective distance — not straight-line, but travel time to pickup on the road network, traffic-aware where a provider matrix is available.
• Current load — a rider mid-delivery pays a penalty proportional to their remaining stops.
• Batching potential — if the new drop is near a stop already on the rider’s route, the score gets a large bonus. Batching is where fleets find 30–40% capacity they didn’t know they had.
• Prep-time alignment — arriving at a restaurant 12 minutes before the biryani is ready wastes the rider; arriving 5 minutes after wastes the customer. The scorer targets the ready-time window.
• Rating and reliability — small weights, used mostly as tie-breakers, so a new rider still gets work.

The output is a ranked plan: Ravi 0.94, Imran 0.71, Deepa 0.58. The top rider gets an offer with an accept timer; a rejection cascades to the next.

Step 3: Explain — why did it pick Ravi?

This is the part most dispatch systems skip and the part operators tell us matters most. Every assignment carries a plain-language explanation: “Ravi: 1.1 km from pickup, no active tasks, arrives as order is packed.” When the system does something unexpected — skipping the nearest rider because their shift ends in 20 minutes — the explanation is the difference between an operator trusting the tool and turning it off.

Trust in automation is built one explained decision at a time, and destroyed by one unexplained bad one.

Dry-run mode: look before it leaps

Teams migrating from manual dispatch start in dry-run mode: the AI produces its full scored plan for every order, but commits nothing. Dispatchers compare the plan against what they would have done. Most teams flip to auto within two weeks — usually right after their first rush hour of watching the plan match or beat their instincts.

What happens when it fails?

Everything degrades gracefully, in order: if the traffic provider is down, scoring falls back to haversine-plus-speed estimates. If the scoring service itself is unreachable, dispatch falls back to manual with the full board still live. Your operation never stops because a model did. And a human can override any assignment with one drag on the dispatch board — the AI logs the override and, in aggregate, learns from it.

The result

Across FleetView fleets, AI dispatch assigns in under 2 seconds at p95, lifts on-time rates into the mid-90s, and cuts per-order dispatch effort from a phone call to zero. Not because the model is exotic — it is mostly disciplined operations research — but because it is fast, explainable, and humble enough to hand control back the moment a human wants it.