How Courier Dispatch and Routing Work in Food Delivery

How it works in short

A delivery dispatcher solves one problem over and over: which courier carries which orders and in what order. In modern services this is not a person with a map but an algorithm running in cycles:

1. collect the order pool — orders that will need a courier soon;
2. collect the courier pool — free couriers and those about to become free;
3. score possible courier-to-orders combinations with a cost function;
4. assign the best options and push tasks to the courier app.

A human dispatcher stays in the loop for exceptions: refusals, accidents, problem addresses.

When to assign a courier

The key idea: the courier should arrive at the restaurant exactly when the order is ready. Too early and they sit idle instead of delivering other orders. Too late and the food gets cold.

So the system estimates:

• preparation time — from the restaurant's history, the dishes in the order and current kitchen load;
• courier travel time to the restaurant;
• assignment moment = ready time minus travel time minus a small buffer.

The restaurant improves accuracy by marking statuses on a tablet or KDS: "accepted", "cooking", "ready". Without these signals the system relies on prediction alone.

Batching orders

Batching means one courier carries several orders in one trip. It saves couriers at peak hours but risks delaying the first order.

Conditions under which batching is usually justified:

• orders from the same or neighboring restaurants;
• delivery addresses along the same route;
• ready times close to each other;
• the added delay for each order stays under a threshold set by the business.

Ordering the stops within a batch is a simplified routing problem (a TSP variant with time windows). For two or three orders you can try every permutation; at larger scale heuristics are used.

Assignment logic

Each "courier + set of orders" option gets a cost, for example:

cost = w1 * time_to_customer
     + w2 * courier_wait_at_restaurant
     + w3 * lateness_vs_promised_eta
     + w4 * courier_distance

The business tunes the weights: what matters more — speed for the customer or courier utilization. The problem then becomes an assignment problem: pick pairs with the lowest total cost. Approaches:

• greedy: assign the best available option one at a time — simple and fast, but not optimal;
• optimization: solve the assignment for the whole pool at once (for example, the Hungarian algorithm or solvers) — better results, harder to build;
• delayed decision: an order waits a few seconds in case a better combination appears.

Vehicle type, thermal bag capacity, courier zone and time left in the shift are also taken into account.

How ETA is calculated

ETA is the sum of stages:

Teams usually start with simple averages per stage and then move to an ML model trained on actual times. It is important to recalculate ETA on every status change and show the customer an honest range rather than an optimistic point.

Tracking architecture

A typical setup:

• the courier app sends GPS coordinates every few seconds, batching points when the connection is poor;
• an ingestion gateway writes them to a queue or stream (Kafka, Redis Streams and similar);
• a location service keeps each courier's latest position in fast storage with a geo index for nearest-courier lookups;
• the dispatcher reads positions and order statuses;
• the customer gets updates via WebSocket or periodic polling.

Practical concerns: filtering GPS jumps, saving battery on the courier's phone, storing track history for dispute resolution and protecting against spoofed locations.

Common mistakes

• Assigning a courier as soon as the order is placed, so they wait in the kitchen.
• Aggressive batching that leaves the first customer with cold food.
• ETA that ignores the "last meters" and the load of a specific restaurant.
• No manual mode for the dispatcher when the algorithm gets it wrong.