Dispatch software: allocating drivers and vehicles on the day

The assignment problem in the execution window

Work has to be attached to a specific driver, a specific vehicle and a specific start time. Each of those carries constraints: the vehicle needs valid roadworthiness and the right body type, the driver needs the licence category and any goods-specific qualification, and the driver's remaining permitted duty must cover the job. Systems that model these as attributes can block an impossible assignment before it leaves the screen. Systems that treat drivers as interchangeable names push the checking back onto memory, which is where infringements and refused loads originate.

Driving time and duty rules are a hard boundary

Road transport in most jurisdictions constrains daily driving, breaks, rest and weekly duty, with tachograph or equivalent records as the evidence. Dispatch decisions are therefore bounded by data the vehicle already holds, and the useful design pattern is to pull remaining availability into the assignment view rather than to calculate it independently. Because the rules and their enforcement differ by country and by vehicle category, configuration should follow the competent transport authority for the operating territory rather than a supplier's default assumption.

Re-planning without rebuilding the day

The characteristic dispatch action is a partial change: pull two drops off one run, push them onto another, and leave everything else untouched. Software that can only re-optimise the whole plan is unusable at this point, because a fresh optimisation invalidates instructions already given to drivers who are already moving. What dispatchers need is a view of committed against uncommitted work, the ability to move individual stops with immediate feasibility feedback, and a record of who was told what and when, since that record settles most later disputes.

The channel to the driver decides whether changes stick

A reassignment only exists once the driver knows about it. Systems push work to an in-cab or handheld application with acknowledgement, and the acknowledgement matters as much as the send, especially when a driver is in a lift, a basement or a poor coverage area. Offline behaviour, message queueing and clear conflict handling when a driver acts on a superseded instruction separate practical tools from demonstration software. The same channel usually carries arrival, departure and delivery confirmations back, which is what keeps the dispatch board honest.

Where dispatch ends and other systems begin

Route optimisation decides the shape of the day before it starts; transport management converts orders into loads and settles the cost afterwards; dispatch owns the hours in between. Blurring those boundaries produces duplicate assignment logic in two systems, and the resulting disagreement about which one holds the current plan is a common source of missed collections. Draw the handover explicitly: one system publishes the plan, one system owns changes after a defined cut-off, and the audit trail follows the second.

Frequently asked questions

Can route planning software be used for dispatch?

Only where the day rarely changes. Planning tools optimise a whole scenario, while dispatch needs surgical edits with immediate feasibility checks, so operators with volatile demand usually need both, connected at a defined cut-off point.

Does dispatch need live vehicle positions?

It functions without them, but decisions get slower and less accurate. Position and status data let a dispatcher see who can realistically take extra work rather than asking by telephone, which is the difference between reacting in minutes and reacting in an afternoon.

How should subcontracted vehicles be handled?

Model them as capacity with fewer attributes and looser visibility, and keep the commercial record separate from the operational assignment. Trying to manage subcontractors as though they were employed drivers usually breaks either the compliance data or the cost data.