The order moves to the closer rider. Not the one who picked it up first.
Reallocation is where dispatch stops being a snapshot and starts behaving like an operation. When a closer or less-loaded rider becomes the better option, the order should not sit with the original rider out of inertia - it should move, and both routes should rebuild, without anyone having to notice.
Four honest reasons an order moves.
Reallocation is not free. Moving an order costs a small handover overhead, so the engine only triggers when the expected outcome improves by more than the cost of the move.
- Window at risk - the current path will miss the promised window with high confidence
- Faster path available - a closer or less-loaded rider will beat the current path by more than the handover cost
- Rider stall - the assigned rider has been stationary or unreachable beyond a configurable threshold
- Batching opportunity - a new order allows a two-in-one dispatch that saves more than the cost of moving one of them
Order 2291 - reallocated
Assigned to R03
R03 was the nearest available rider at 16:04, given a 20-minute window.
R03 slowed
Pickup queue at origin longer than modelled. Predicted window slips by 6 min.
Alternatives scored
Engine tests R05, R09, R12. R09 has just cleared their queue two blocks north.
Move accepted
R09 reaches origin 2 min ahead of R03's revised ETA. Move accepted, both routes rebuild.
Delivered
Order 2291 lands at 16:23, three minutes inside the original window. Reason logged.
Reallocation is a trade-off, not a preference.
Time saved
Difference between the current predicted window and the alternative rider's predicted window - the primary gain.
Handover cost
Small overhead for the original rider to be told, the app state to sync, and the new rider to route back. Real and modelled.
Fleet-wide impact
What happens to the original rider's remaining path once the order is removed - is it faster, or does it just get lopsided?
SLA weight
A tighter SLA increases the value of saved minutes - a hard-window order will trigger reassignment on a smaller margin than an ASAP.
Confidence
How sure the engine is about both windows. A high-confidence miss is treated differently from a low-confidence one.
Recent moves
Guardrail against thrashing - an order that has already been moved once carries a higher bar for moving again.
What reallocation will and will not do.
Guardrails
Every reassignment writes a reason line to the audit log - what changed, how much time it expected to save, and what the outcome was. You can review any move after the fact.
Rider fairness
Reallocation runs against a configurable fairness constraint so the same rider does not repeatedly lose orders they were doing fine with. Fleet managers set the ceiling.
Manual override
Dispatchers can hold an order in place with a single click. The engine will stop proposing moves for that order until the hold is cleared.
Next in the loop
A reassignment the customer never notices is the point. See how tracking and notifications stay in sync.
Show us your fleet size. Watch the swarm move at your scale.
Type a rider count and a rough daily order volume. The view on the right rebuilds to that scale, with a sample reassignment playing every few seconds - the same kind of decision the delivery engine makes for a live fleet.
An illustrative view based on typical patterns - not a live read of your actual fleet. Numbers move with your inputs so you can see the shape of the problem the engine solves.