Why delivery windows slip even when driving time is accurate

An ETA can be built on perfect traffic data and still be wrong by early afternoon. Most planning software gets the driving right, the map, the traffic, the distance between stops. What it often gets wrong is what happens once the driver arrives. When that number is guessed at instead of calculated, planners spend the afternoon rebuilding a schedule that drifted for reasons that had nothing to do with driving, support fields the calls that drift creates, and drivers absorb a day that runs later with every stop.

This gap shows up in the calculation, not in slow driving or heavy traffic.

Driving time was never the hard part

Mapping and traffic data have been solved reasonably well for years, so most planning tools treat travel time as settled and move on. The variable that's usually still guessed at is what happens at the stop itself, not the road leading to it. A flat average applied to every delivery is where a plan quietly starts drifting from reality, even while the driving portion underneath it stays accurate the whole time.

One flat number standing in for very different stops

A curbside drop and a fourth-floor delivery with no elevator are not the same job, even when they're five minutes apart on the map. Among the variables that change how long a stop takes, weight, volume, and order type shift the picture, and so do floor access, parking availability in dense areas, and whether a delivery includes installation or assembly. A plan that assigns the same average to all of it isn't simplifying the problem, it's guessing, and the guess compounds. A stop that runs ten minutes over doesn't just make that stop late, it pushes every stop behind it later too.

A flat average isn't fair to the driver, either

Two drivers can run the same number of stops in a day and face completely different workloads, one route full of ground-floor drop-offs, the other full of walk-ups and two-person jobs. When the plan assumes both took the same effort, that assumption carries into performance data, into workload balancing, and into how routes get compared across a network. A driver working a structurally harder route looks less efficient than one who isn't, not because of anything they did, but because the plan never saw the difference in what each stop required.

This same distortion shows up when comparing routes and carriers. Cost and performance metrics are only comparable if they're anchored in real effort at each stop. Built on a flat average instead, two routes that look identical on a scorecard can represent very different amounts of work.

The same stop, three plans, three different outcomes

Consider one delivery scheduled at four minutes, the network average.

• A ground-floor drop-off finishes in three minutes. The plan was close enough, and the day stays on schedule.
• A fourth-floor delivery, same order, takes eleven minutes with no elevator. The plan didn't know the building, so it never adjusted, and the next four stops start absorbing the difference.
• An assembly job planned as a standard drop-off runs twenty-five minutes over, because the plan had no way to flag it as requiring more than a handoff at the door.

Only one of these three stops matched what the plan assumed. By the time the driver reaches stop ten, the schedule reflects the average the plan used, not the day the driver had.

This shows up wherever task time varies by stop

In big and bulky and assembly delivery, job time varies enormously by service tier and access conditions, and a flat average erases most of that variation before the route even starts. In direct-store delivery, stop duration depends on store layout and receiving process as much as order size. Among operations running enough daily volume for it to matter, the same pattern tends to hold, a plan built on one average for every stop will drift further from reality as the mix of stops gets more varied, not less.

The takeaway

Compare the task time your plan assumes for a stop against how long that stop really takes on an easy day and a hard one. The size of that gap is roughly the size of the drift showing up in your ETAs, your workload balance, and your performance data.