How Auto-Dispatch Scores a Driver

Auto-dispatch finds a driver for a delivery order without anyone deciding. It is the difference between a dispatcher watching a screen all evening and a system that only needs attention when something is wrong.

The question operators actually ask, usually after the third complaint of a shift, is narrower: why did that driver get that order? This post answers it — the inputs, the filters in front of them, and which of them you can move. The reference page is Auto-dispatch in the docs.

First: when the search starts

Before anything is scored, you choose the trigger status — the point in the order’s life at which the search begins. Two options:

• Processing (order confirmed). The driver arrives as the food does. Better for the customer, and the usual choice where preparation times are honest.
• Ready (ready for pickup). No driver ever waits, at the cost of a gap after the food is packed.

Trigger at Processing and preparation time is doing the work: it decides both what the customer is quoted and when a driver is called. If prep times are optimistic, triggering early converts that optimism into drivers standing around, which is a merchant conversation rather than a dispatch setting.

The four weights

When the search runs, four weights decide who is offered the order first.

Distance. How far the driver is from the pickup. Raise it to keep deliveries tight and driving time down.

Current load. How many orders that driver is already carrying. Raise it to spread work evenly across the fleet rather than repeatedly loading whoever happens to be closest.

Driver type. A bonus applied by the kind of driver, which is how you bias toward a class of the fleet — the employed drivers over the freelance ones, or the vehicle class that suits the run.

Past acceptance. How reliably that driver has taken offers. Raise it to favour drivers who actually accept, which shortens time-to-assign at peak because fewer offers are spent on people who will decline.

The one piece of tuning advice that matters more than any individual weight: change one at a time and watch the analytics. Move several and you will not know which did what, and the shift you are measuring against is never repeated exactly.

Vehicle type lives one level up, in driver groups

“Score by vehicle” is the request; the mechanism is slightly different, and the difference is useful.

A driver group is where one set of rules applies to many drivers, and it carries three things: vehicle types (bicycle, bike, car, minivan, truck or boat), conditions — which business types and zones the group covers — and pay rules, whether that is a flat amount per order, a percentage, a per-distance rate with a base distance, a share of the delivery fee, a share of tips, or time-based components.

So a mixed fleet is managed by grouping rather than by scoring each person. Cyclists on short urban runs and drivers on long suburban ones need different pay, different coverage and different dispatch radii, and a group is where that difference lives instead of on twenty individual records. The driver-type weight then biases between classes; the group decides what work a class is eligible for at all. See Drivers.

Availability is a filter, not a weight

A driver who scores brilliantly and is not eligible is never offered the order. Several gates sit in front of the scoring, and when a driver says they “never get offers” the answer is almost always one of them:

• Online status. Location is shared and offers are received only while the driver is online.
• Dispatch radius, set globally or on their group.
• Concurrent-order cap — how many orders one driver may hold at once.
• Group zones and business types, from the group’s conditions.
• The outlets they are assigned to.

The mirror image is a driver who stays online after their shift and keeps receiving offers. Auto-dispatch has timeouts for exactly that, but the real fix is a habit rather than a setting.

How the offer is made

Scoring decides the order of the queue; the method decides how the queue is worked.

One-by-one is fairest to drivers and slowest at peak. Broadcast is fastest and can leave drivers feeling they are racing for work. Forceful assignment is for employed fleets where accepting is not optional. Each carries its own tuning — a rejection cooldown for one-by-one, so a driver who declines is not immediately re-offered the same order, and a cap on how many drivers a broadcast reaches.

Two pools, and who is tried first

Your own drivers and aggregator drivers are configured separately, each with its own enable switch, priority, dispatch radius and concurrent-order cap. You choose which pool is tried first, and what happens when the first is exhausted: try the next in sequence, run both in parallel, or weight between them. Aggregator drivers can be restricted further by zone and by driver group, which is how a specialist fleet stays on the work it exists for.

With cost comparison on, auto-dispatch weighs the cost of your own driver against a delivery network quote before deciding, using a per-kilometre rate and base fee you set, plus a bonus that biases toward in-house when the two are close. Turn it on once your own delivery costs are actually known — before that, the comparison is against a guess.

When nobody accepts

The fallbacks are as much a part of the configuration as the weights:

• Acceptance timeout — how long a driver has before the offer moves on.
• Retry attempts and delay — how many times the whole search repeats.
• Driver-offline handling — a grace period for a driver who drops off the network, and a separate timeout for one who accepted and then went offline, so an order is not stranded with someone who has gone home.
• Notify on no driver — tell the merchant when the search fails, which is the moment a human needs to know.

Staff can always cancel the search from the order and assign by hand from the dispatcher panel. Never remove that: automation should be the default, not the only path.

Rolling it out, and what to watch

Start with one outlet — a per-outlet override forces dispatch on or off regardless of the global setting. Start with one-by-one, a generous acceptance timeout and the default weights, because it is the least surprising to drivers. Use the simulation first: it shows who would be offered an order without offering it. Then watch for a week, change one thing, and widen once assignment rate and time-to-assign look right.

The two numbers that matter are time to assign and failed searches, both in Auto-Dispatch Analytics. And the most common finding is not a configuration one: a rising time-to-assign at peak usually means too few drivers online, and no amount of tuning fixes a supply problem.

Want to see the weights, the simulation and the analytics on a live marketplace? Book a demo.