Dispatch and routing engines: assigning the right rider in seconds
How does dispatch engine development work, and how does an engine assign the right rider in seconds?
Dispatch batches orders by area and window, proposes assignments with routing rules and lets operations override on a live map. A good engine scores candidate riders every few seconds for each unassigned order, with rules the operations team can read and a shadow mode that proves each change before it goes live.
Dispatch engine development is the work of turning a stream of new orders and a map of available riders into assignments that are fast, fair and explainable. The engine batches unassigned orders by area and delivery window, scores each candidate rider for each batch using travel time, current load, vehicle and merchant readiness, proposes an assignment, and shows it to operations on a live map where a person can override. Done well it runs in seconds, degrades safely when data is missing, and can be tuned by the operations team without an engineer. This article covers the engine we build inside super app development and logistics platforms: the loop, the scoring, the routing, the override, and how to change it safely.
What a dispatch engine is and what it is not
It is not a single optimisation solve. Orders arrive continuously, riders move, merchants are late, and the best answer changes every minute. A dispatch engine is therefore a loop: collect unassigned orders, group the ones that can share a trip, score riders for each group, commit assignments that clear a confidence threshold, and hold the rest for the next cycle or a person. Route optimisation for planned parcel rounds is a separate tool that can sit inside the loop for multi-stop batches, but the loop is the product.
The engine loop, step by step
| Step | What happens | Typical cadence | What can go wrong |
|---|---|---|---|
| Ingest | New orders, rider locations, merchant status and cancellations arrive on a queue | Continuous | Stale rider locations; treat older than a threshold as unknown |
| Batch | Orders grouped by pickup area, drop direction and promised window | Every few seconds | Batching too greedily delays the first order in the batch |
| Candidate selection | Riders within a radius, on shift, with capacity and the right vehicle | Per batch | Empty candidate set; widen radius or flag for ops |
| Scoring | Weighted score per rider: travel time, load, merchant readiness, fairness | Per batch | Weights nobody understands; keep them readable |
| Commit or hold | Assign above a threshold; hold ambiguous cases for the next cycle or a person | Per batch | Committing low-confidence assignments to keep the queue empty |
| Offer and accept | Rider receives the offer with a timeout; decline returns the order to the queue | Seconds | Riders gaming offers; track decline patterns |
| Monitor | Assignments tracked against ETA; late or stuck deliveries raised as exceptions | Continuous | Exceptions with no owner; route them to a queue |
Scoring: readable rules before clever models
The first version of the scoring function should be a short list of weighted terms that the operations lead can read aloud: estimated travel time to pickup, remaining stops on the rider's current trip, whether the merchant has confirmed the order is ready, vehicle suitability for the parcel, and a fairness term that spreads work across riders on shift. Each term is normalised and weighted; the weights live in configuration, not code, with a change log.
Machine-learned ETAs and demand forecasts come later, and they improve the inputs to the score rather than replacing it. An ETA model trained on the platform's own delivery history is the most valuable upgrade, because travel time dominates the score and map-service estimates rarely reflect a two-wheeler in a specific city at a specific hour. The demand forecasting guide covers forecasting, which feeds rider scheduling more than live dispatch.
Fairness and rider earnings
An engine that always picks the nearest rider starves riders at the edge of an area and burns out those in the middle. The fairness term, with a cap on consecutive assignments and a floor on idle time, keeps earnings spread. Riders notice unfair dispatch within days and leave; the term is not a nicety.
Routing: the delivery routing algorithm inside the loop
For single-stop orders, routing is a travel-time lookup between rider, merchant and customer. For batched multi-stop trips, the engine must order the stops. A simple nearest-neighbour ordering with a time-window check is enough for batches of two or three; larger batches, common in grocery and parcels, justify a proper vehicle-routing solver. Google's open-source OR-Tools routing library is the primary reference for that class of problem and is what we usually embed rather than writing a solver from scratch.
Travel times come from a road network with traffic where available, cached aggressively and corrected by the platform's own history. The engine never blocks on a routing API; if a lookup is slow or fails, it falls back to a distance estimate and flags the assignment as lower confidence.
The live map and the override
Operations sees every active order and rider on a map with the engine's proposed assignments, the reasons behind each in plain words, and the exception queue. A dispatcher can reassign, hold, split a batch or close an area, and each override is recorded with a reason. Overrides are the most valuable dataset the engine produces: a cluster of them in one area or at one hour is a rule the engine is missing. Review them weekly.
The console is a real product with its own users, and it is where a dispatch platform proves itself to the operations team. The dispatch platform and offline-first driver app case study describes one built for a last-mile operator, including the map, the exception queues and the rider app the assignments flow into.
Changing the engine safely: shadow mode and evals
Every change to weights, batching rules or the ETA model runs in shadow first: the new version scores the same live orders alongside the current one, its proposals are logged but not committed, and the two are compared on assignment time, predicted lateness, rider utilisation and how often a dispatcher would have overridden each. Only a version that wins on the metrics the operations lead cares about is promoted, and by area rather than everywhere at once.
Keep a replay set of historic days, including a festival peak and a rain day, and run every candidate against it before shadow mode. This is the same evals-before-demos discipline we apply to AI agents, described in shadow mode: the right way to launch AI in production, and it is what makes an operations lead willing to let the engine decide more unattended.
Where AI agents fit around the engine
The engine assigns; agents handle what it cannot. A stuck delivery, a merchant who has not confirmed in ten minutes, a customer whose pin is wrong: each is an exception that today goes to a dispatcher's phone. An exception-handling agent can call the merchant, message the customer to confirm the address, or propose a reassignment for a dispatcher to approve, every action policy-gated. The pattern is in AI in logistics: dispatch, exceptions and customer updates, and it depends on the engine exposing exceptions as structured events rather than screen alerts.
A worked example
A last-mile operator in two cities assigned orders by hand from a spreadsheet and a group chat. Assignments took minutes at quiet times and fell apart at peaks; central riders were overloaded while riders at the edges waited. A routing product that produced a daily plan had proved useless for orders arriving every minute.
The engine was built as the loop above, with five readable scoring terms and weights the operations lead controlled from the console. Batching was limited to two orders in the same direction to protect the promised window. Travel times came from a cached road network, corrected by the platform's own completed deliveries after the first month. The engine ran in shadow for three weeks against the manual process before committing assignments in one city, then the other. Overrides were reviewed weekly and several became rules. An ETA model trained on the platform's history replaced map estimates in the second quarter, and an exception agent for merchant confirmation followed. The wider context is on the logistics industry page.
Team and timeline
A dispatch engine is a backend lead with optimisation experience, two backend engineers, a front-end engineer for the console, a data engineer for the event and replay pipeline, and a QA engineer; later phases add an ML engineer for ETA and forecasting. Your side provides the operations lead who sets weights, reviews overrides and signs off each promotion from shadow mode.
As part of a full platform it sits inside super app development from $63,000 (₹41.6L). As a standalone engine and console added to an existing delivery product, it is typically ten to fourteen weeks under product and platform development from $42,000 (₹28L), with the ETA model as a follow-on AI/ML development engagement from $17,500 (₹11.2L). A three-week ProofRun at $6,250–10,500 can run a candidate engine against your replay data before you commit. Running the engine through peaks needs a Standard or Enterprise Care Plan; see the pricing page.
Before you start: a checklist
- Capture rider locations, order events and merchant confirmations as a stream before building the engine
- Write the first scoring function as five or six readable terms with the operations lead
- Decide batching limits that protect the promised window
- Choose the road-network and travel-time source, and the fallback when it is slow
- Design the offer and decline flow in the rider app, including timeouts
- Build the replay set from historic days, including a peak and a bad-weather day
- Agree the shadow-mode metrics and who signs off promotion by area
- Record every override with a reason and schedule a weekly review
Glossary
- Batch: a group of orders assigned to one rider as a single trip
- Candidate set: riders eligible for a batch after radius, shift, capacity and vehicle filters
- Scoring function: the weighted combination of terms that ranks candidates
- Commit threshold: the confidence below which the engine holds an assignment for a person
- Override: a dispatcher changing the engine's proposal, recorded with a reason
- Shadow mode: running a new engine version on live orders without committing its assignments
Related reading
Continue with building a multi-vertical delivery platform in India, exception handling agents for deliveries, and logistics ERP: fleet, dispatch, settlements and reconciliation.
Score in the open, commit only what you are confident in, let people override and learn from every override; that is a dispatch engine the operations team will trust.
Frequently asked questions
Does a dispatch engine need machine learning?
▾
Not at first. A readable weighted scoring function with tunable weights handles most platforms well. Machine learning earns its place later by improving ETAs and demand forecasts, which are inputs to the score rather than replacements for it.
How fast should rider assignment be?
▾
The loop runs every few seconds, so a typical order is proposed within seconds of merchant confirmation. Batching deliberately waits a short, bounded time to find a second order in the same direction without breaking the promised window.
How do we change dispatch rules without disrupting operations?
▾
Run the new version in shadow mode against live orders, compare it on lateness, utilisation and overrides, replay it against historic peak days, and promote it one area at a time with the operations lead's sign-off.