The driver is ready. The model is late.
Your delivery manager must send a driver out while the route model is still updating. Waiting feels responsible: surely the shortest predicted route makes the service cheaper. But customers pay for completed deliveries, and you pay for the driver's waiting time too.
Put the wait on the clock
Consider one hypothetical delivery business; every value here is assumed, not a reported result. Its driver has 240 minutes until the delivery cutoff. Assume an updated route takes 210 minutes, including stops, while a checked standing route takes 225. Driver pay varies with duty time at $24 per hour; all other costs and customer charges match.
Waiting 30 minutes for the update uses 30 + 210 = 240 minutes and costs 240 / 60 × $24 = $96. Dispatching the standing route now uses 225 minutes and costs 225 / 60 × $24 = $90. Both meet the assumed cutoff; the fallback costs $6 less and leaves 15 minutes for delay.
Inspect the recommendation, then dispatch
The model ranks travel and stop time; a delay before departure sits outside that estimate. Refreshing the screen need not refresh the calculation. Compare the route's “generated at” time with the dispatch list's last change; check that every stop matches. If a stop changed after calculation or is missing, rebuild the estimate before using it.
Run a rehearsal with a stalled update: confirm the standing route covers every required stop, then record departure and completion times. Under these assumptions, dispatch it now. If neither route fits the remaining time, revise the service commitment before promising it.
A faster update changes the answer
Now suppose the same update arrives in five minutes. Waiting uses 5 + 210 = 215 minutes and costs 215 / 60 × $24 = $86. Choose the updated route if its inputs are current. Its driving advantage buys at most 15 minutes of waiting: below that threshold it wins; above it, the checked fallback wins. These are planning estimates, so compare actual completion with the cutoff.