Building the Dispatch Engine: Driver Assignment, Batching and Live Order Tracking

The Part of Delivery Software That Decides Everything

Customers judge a delivery business on one number: how long the food took, measured against what they were promised. Restaurants judge it on a different one: how many orders went out per driver hour. Both are decided by the same piece of software, and it is almost never the part that gets designed carefully.

The dispatch engine — the logic that decides which driver takes which order, when they leave, and in what sequence they deliver — is where delivery operations are won or lost. Get it right and a three-driver operation handles a Friday night that would otherwise need five. Get it wrong and you get cold food, drivers arguing over the good jobs, and a tracking map that shows a driver going the wrong way.

This is what we have learned building dispatch and driver tracking for real delivery operations, including the driver app behind Italian Pizza UK.

Start With the Timeline, Not the Map

The instinct is to think about dispatch spatially — which driver is closest. That is the wrong starting point, because delivery is a timing problem with a geography component, not the other way round.

An order has a sequence of moments: placed, accepted by the kitchen, cooking, ready, collected by a driver, in transit, delivered. Dispatch decisions depend on predicting the cooking-to-ready transition accurately, because a driver dispatched too early stands in a kitchen doing nothing, and a driver dispatched too late leaves food sitting under a heat lamp.

That prediction is the foundation. Practical approaches, in increasing order of sophistication:

• A fixed prep time per restaurant. Crude but workable for a single site with consistent output.
• Prep time per menu category, since a burger and a slow-cooked dish are not the same.
• Dynamic prep time based on current kitchen load, which is the point at which the estimates become genuinely good. Ten orders in the queue means the eleventh takes longer, and any system that ignores that will be consistently wrong exactly when accuracy matters most.

Every downstream feature — the customer's estimated delivery time, the dispatch decision, the tracking map — inherits the accuracy of this one prediction. Teams that build the map first and the prediction later end up with a beautiful tracking screen showing a driver who was dispatched at the wrong time.

Assignment Strategies and What They Cost

Once you know when an order will be ready, you need to decide who takes it. There is no universally correct strategy, and the right one depends on fleet size and order density.

• Manual assignment. A dispatcher drags orders to drivers. This is genuinely the best option below roughly 200 orders a day with a small fleet, because a good dispatcher who knows the area and the drivers outperforms naive automation. Build the tooling to make manual assignment fast rather than pretending it does not happen.
• Nearest available driver. Simple, and it works reasonably. Its weakness is greediness — assigning the nearest driver to an order that is ready now can leave nobody suitable for an order that becomes ready in four minutes on the same street.
• Offer and accept. The order is broadcast to eligible drivers and the first to accept takes it. Popular with self-employed fleets because it preserves driver autonomy, but it produces cherry-picking, where short profitable runs get taken instantly and awkward ones sit unassigned.
• Batched optimisation. Every 30 to 60 seconds, the system considers all unassigned orders and all available drivers together and produces an assignment that minimises total lateness. This meaningfully outperforms per-order decisions at density, and it is considerably more work to build and tune.

The pragmatic path we recommend for most operations is manual assignment with strong tooling first, then nearest-driver automation with a manual override, then batched optimisation only if order density genuinely justifies it. Building a sophisticated optimiser for a fleet of four drivers is engineering for its own sake.

Batching Multiple Orders Per Trip

Sending a driver out with one order at a time is simple and expensive. Batching two or three deliveries into one trip is where delivery economics improve, and where customer experience degrades if handled carelessly.

The rules that make batching work:

• Only batch orders whose drop-off points are genuinely on a sensible route, not merely within a radius. Two addresses a mile apart in opposite directions from the restaurant are not a batch.
• Cap the detour cost for the first customer. A customer whose food is delivered second should not wait more than a few extra minutes because of it.
• Never batch across a food-quality boundary. Ice cream and hot pizza in the same bag for 25 minutes is a refund.
• Sequence the drop-offs explicitly and show the driver the order. Leaving the sequence to driver judgment produces exactly the "why did they drive past my house" complaint that erodes trust in the tracking screen.

Batching is also where the tracking map becomes confusing for customers. A driver visibly heading away from the customer's address is alarming unless the interface explains that there is one stop before theirs. Showing "you are stop 2 of 2" costs nothing and prevents a support call.

Live Location Without Destroying Battery

Live tracking is a mobile engineering problem more than a backend one. A driver app that flattens a phone battery by 2pm will simply be closed by drivers, and then the tracking stops.

What works in practice:

• Use the platform's significant-change and background location APIs properly rather than a naive timer that requests a fix every few seconds. Both iOS and Android provide batched, power-efficient background location, and both aggressively restrict apps that abuse foreground location.
• Vary the update frequency by state. A driver idle at the restaurant needs an update every 30 to 60 seconds. A driver approaching a drop-off needs one every 5 to 10 seconds. Streaming at maximum frequency all day is wasteful and unnecessary.
• Use geofencing for state transitions. Arriving at the restaurant and arriving at the customer are events the operating system can detect for you far more cheaply than polling coordinates and computing distance yourself.
• Batch uploads. Sending each fix as its own request is expensive in radio wake-ups. Buffering a few points and sending them together is materially kinder to the battery.
• Handle the permission reality. Drivers will deny background location, revoke it after an OS update, or enable battery saver mode. The app must detect these states and tell the driver plainly what to fix, because the alternative is a dispatcher looking at a map with a driver who has silently disappeared.

On the transport layer, WebSockets are the right default for pushing driver positions to customers and dispatchers. We use Laravel Reverb for this on our own stack, and the pattern is the same regardless of the tool: drivers publish to a private channel, dispatchers subscribe to all of them, and each customer subscribes only to the channel for their own order.

What the Customer Should Actually See

Tracking screens are frequently over-engineered. Customers do not want telemetry, they want reassurance. The hierarchy of what actually reduces anxiety and support contacts:

• A clear status in words. Preparing, on its way, two minutes away. This does more work than the map.
• An estimated arrival time that is honest, including when it slips. A quietly changing estimate is worse than an explicit "running about 10 minutes late" message.
• The map, once the driver is genuinely in transit. Showing a map before the food is collected invites confusion.
• A way to contact the driver that protects both phone numbers, which means number masking rather than exposing mobile numbers to each other.
• Proof of delivery at the end — a photo for contactless drop-offs, or a name for handovers.

Resist showing the driver's location while they are on an earlier delivery in a batch. It creates precisely the confusion described above with no benefit.

Driver Experience Determines Data Quality

Everything the dispatch system knows comes through the driver app, so a bad driver app produces bad data, and bad data produces bad decisions.

What drivers need, based on watching them work rather than asking in a meeting:

• Large tap targets, high contrast, and a layout usable one-handed with a helmet on and gloves.
• One clear next action per screen. A driver at a set of traffic lights should never have to navigate a menu.
• Handoff to whichever navigation app they already prefer, rather than an in-app map they will ignore.
• Offline tolerance. Deliveries happen in basements, multi-storey car parks, and rural dead zones. Status updates must queue locally and sync when signal returns, with a visible indicator of what is pending.
• Earnings visibility. Drivers check this constantly. Making it accurate and immediate removes a substantial share of support conversations.
• A simple way to report a problem — customer not answering, wrong address, access issue — with the outcomes the operator actually needs to act on.

The single biggest data quality improvement we have made on any delivery project was making the "delivered" button impossible to miss and adding a photo step. Before that, drivers were marking batches delivered at the end of a run, which made every timing metric in the system fiction.

Handling the Things That Go Wrong

Dispatch systems are judged on their failure paths. The ones that must be designed rather than discovered:

• Driver rejects or fails to respond. Define the timeout, the reassignment logic, and the escalation to a dispatcher. Silent unassigned orders are the worst possible outcome.
• Driver goes offline mid-delivery. Detect stale location data, alert the dispatcher, and provide a manual reassignment path with the order's current state intact.
• Customer not available. A defined wait period, a contact attempt, a photo, and a clear rule about what happens to the food and the payment.
• Restaurant cancels after collection. Rare but messy, and it needs a refund and driver compensation path.
• No drivers available at all. The system must be able to stop accepting delivery orders or extend quoted times automatically rather than continuing to promise 30 minutes.

That last one is the most commercially important. A platform that keeps taking orders it cannot fulfil converts a busy night into a wave of refunds and one-star reviews.

Measure These, Not Vanity Metrics

The metrics that actually drive improvement in a delivery operation:

• Promised versus actual delivery time, as a distribution rather than an average. The tail is what customers remember.
• Time from ready to collected. This isolates dispatch quality from kitchen and traffic factors.
• Driver idle time as a share of shift time, which tells you whether you are over- or under-staffed at each hour.
• Deliveries per driver hour, the core economic number for the operation.
• Reassignment rate, which is a direct measure of how well the assignment logic is working.
• Late-order rate by hour and by zone, which usually reveals a specific problem — one zone that is consistently underserved, or one shift handover that is badly timed.

Averages hide everything that matters here. An operation with a 32-minute average delivery time and 12% of orders over an hour has a serious problem that the average conceals entirely.

Build It in the Right Order

If you are starting a delivery build, the sequence that produces a working operation fastest is: accurate prep-time prediction, then a dispatcher screen with fast manual assignment, then the driver app with reliable status updates and offline queueing, then customer tracking, then automated assignment, and only then batching and optimisation.

Almost every team that struggles with delivery software built that list backwards, starting with the map because it demos well.

We build ordering platforms and the driver apps and dispatch logic that sit behind them, and we have watched all of the failure modes above happen in production. If you are planning a delivery build or trying to fix a dispatch process that is costing you drivers, our contact page is the place to start.