Dispatch is where a food delivery platform earns or loses its margin. Assign a rider too early and they wait at the restaurant. Assign too late and the food goes cold. Batch two orders that are close together and you save a trip; batch them badly and the first customer gets cold fries.
Software can automate the decision, but the rules matter more than the algorithm. A simple rule set that matches your city usually beats a sophisticated optimiser fed with bad data.
| Model | How it works | Best for | Risk |
|---|---|---|---|
| Manual | Dispatcher assigns each order | Small fleet, unusual zones | Slow at peak; depends on one person |
| Auto | Rules assign nearest/least-loaded rider | Dense, standard zones | Bad rules create unfair or inefficient assignments |
| Hybrid | Auto-assign, dispatcher overrides | Most growing platforms | Needs clear escalation and override logging |
| Batching | One rider carries multiple orders | Dense corridors, low order values | Latency and customer experience |
The assignment inputs that matter
- Rider distance to restaurant — not distance to customer.
- Current load — number of active orders and estimated completion time.
- Vehicle type — bike, scooter, car, walker; not every order fits every rider.
- Zone permissions — a rider may not be insured or allowed outside a zone.
- Restaurant prep time — assigning before the food is ready wastes rider time.
- Customer promise — a late order may need a closer rider even at higher cost.
Why “nearest rider” is not enough
The nearest rider may already have two orders, be on a break, or be on the wrong side of a river. A better rule combines distance with load and prep time. If the restaurant needs 15 minutes to cook, sending a rider who arrives in two minutes creates 13 minutes of paid waiting.
Good dispatch software estimates ready time and assigns against it. If your current process assigns on order acceptance, you are probably paying riders to wait.
Batching without hurting customers
Batching works when the pickup and drop-off points are close and the prep times align. It fails when the second order adds 15 minutes to the first customer's delivery. Set a hard latency budget: no order should exceed the promised time by more than a few minutes because of a batch.
Start with manual batching in one corridor. Measure on-time rate and cost per delivery before and after. If the cost falls but late orders rise, the batch is not working; it is borrowing from customer trust.
The rider states you need
Offline, available, assigned, en route to pickup, at pickup, picked up, en route to customer, delivered, failed, returned. Each state should trigger a customer notification and a timestamp. Without timestamps, you cannot diagnose a late order or settle a dispute.
Metrics that reveal dispatch quality
| Metric | What it tells you |
|---|---|
| Rider wait time at restaurant | Prep-time accuracy and early assignment |
| On-time delivery rate | Customer promise reliability |
| Deliveries per rider-hour | Fleet utilisation and density |
| Cost per delivery | Unit economics |
| Reassignment rate | Rule quality and rider acceptance |
| Failed delivery rate | Address quality, rider support, fraud |
What to test before buying
- Create an order and watch the assignment decision.
- Reject the order as the restaurant; does the rider get released?
- Mark the restaurant ready; does the customer notification fire?
- Change a rider's zone mid-shift; does dispatch respect it?
- Run two orders from one restaurant; can they be batched?
- Simulate a rider no-show; who reassigns and what does the customer see?
See Foodomaa's management software, the fleet management guide, or COD reconciliation.