Dispatch engine

A dispatch engine takes a stream of tasks and a live picture of supply (who is available, where, with what capacity and skills) and decides who does what. It scores candidates on distance or travel time, current load, service-level deadlines, skills or vehicle type, cost and fairness, then assigns, batches or holds the task. Assignments are revisited as conditions change: a rider goes offline, an order is cancelled, traffic makes a promised time impossible.

In practice the engine is a rules layer over a scoring model, with an exceptions queue for what it cannot resolve. Rules encode business policy (never assign cold-chain orders to a two-wheeler; prioritise premium customers), scoring handles trade-offs, and humans handle exceptions from a control tower that shows why each decision was made. Route optimisation, which plans the best sequence of stops for a vehicle, is a related but separate problem often used inside dispatch.

Dispatch is not the same as marketplace liquidity; the engine allocates supply that exists. It is also not a scheduling tool for planned work weeks ahead, though the two often share data.

• Operations head: dispatch decisions set delivery times, utilisation and cost per job; the engine is the operating model in code.
• CTO / Head of Engineering: the engine must make decisions in seconds under changing data, which is a real-time systems problem, not a batch report.
• CFO: small improvements in assignment quality show up directly as fewer kilometres, fewer idle workers and fewer missed service levels.
• Support manager: explainable assignments let agents answer why an order was late or reassigned without escalating to engineering.

Dispatch engines exist because manual assignment breaks past a few dozen concurrent jobs, and because the trade-offs between speed, cost and fairness are too many to hold in a dispatcher's head. Encoding them lets the operation scale without adding coordinators, and makes decisions consistent and explainable. The trade-off is that the engine only knows what it is told; bad location data, stale availability or missing constraints produce confidently wrong assignments. The exceptions queue and monitoring are as important as the algorithm.

• A hyperlocal delivery company assigning orders to riders by distance, current load and promised time.
• A field service business dispatching technicians by skill, parts on hand and SLA deadline.
• A hospital transport service allocating ambulances and patient transfers across a city.
• A logistics operator batching shipments onto vehicles by capacity, route and time window.
• An on-demand tutoring platform matching learner requests to available tutors by subject and language.

Tool / technologyA software component that is usually custom-built around a company's own rules and constraints, sometimes using optimisation libraries. Eazyware builds dispatch engines, control towers and driver apps under the product and platform development service, as in its logistics dispatch work.

Eazyware service that covers it: Product & Platform Development. Starting prices are on the pricing page.