Ask a planner what service time they use and you will often get a single number: eight minutes, ten minutes, "about a quarter of an hour". Ask what the actual spread is and you usually get a shrug.
This one field does more damage to route plans than any algorithmic weakness, because it enters the calculation dozens of times per route and its errors accumulate in one direction.
What service time actually includes
Service time is arrival to departure. In a delivery operation that is:
- Parking and manoeuvring, including waiting for a bay
- Walking to and from the vehicle, possibly several times
- Waiting for a receiver to be available
- The physical handover
- Paperwork, signature, photograph, temperature check
- Returns, empties, cages and pallets
- Re-securing the load
Note how much of that is not the delivery. In city-centre retail, parking and access frequently exceed the handover itself. In a rural round the drive dominates and service time is short. This is why borrowed benchmarks are useless.
The cost of getting it wrong
Consider a 40-stop route where you model 8 minutes and the true average is 11.
`` Under-modelled per stop : 3 minutes Stops : 40 Daily shortfall : 120 minutes ``
Two hours of unplanned work, every day, on every route with that error. The visible symptoms are familiar: chronic overtime, missed late windows, drivers "not following the plan", planners padding routes with invisible fudge factors, and eventually a general belief that the routing system does not work.
Over-modelling is less painful but not free: routes finish early, vehicles run under-loaded, and you pay for capacity you did not need.
How to measure it properly
Use telematics and app data, not a stopwatch study. You almost certainly already have arrival and departure timestamps from geofences or from proof-of-delivery events. That is a census, not a sample.
Clean it first:
- Discard stops where the gap includes a break (look for durations above a threshold, typically 45+ minutes).
- Discard the first and last stop of each route where depot activity contaminates timing.
- Separate arrival-to-start from start-to-completion where you have both, because waiting time behaves differently from work time.
- Remove days with known abnormalities — vehicle breakdown, systems outage, snow.
Then build the distribution. Look at the median and the 80th percentile, not just the mean. A stop with a median of 7 minutes and an 80th percentile of 25 is not a 9-minute stop; it is a stop with an access problem you should be solving.
Building a service time model
A usable model has three layers.
Layer 1 — customer-specific. Where you have 10 or more visits to a customer, use their own median. This alone typically captures most of the available accuracy.
Layer 2 — segment defaults. For new or infrequent customers, use a default by segment: premises type, delivery method, drop size band, access category. Something like:
| Segment | Median | 80th percentile |
|---|---|---|
| City-centre retail, kerbside | 14 min | 26 min |
| Retail park, dedicated bay | 8 min | 13 min |
| Residential doorstep | 3 min | 6 min |
| Hospitality, cellar drop | 18 min | 34 min |
| Industrial, forklift unload | 22 min | 41 min |
Those figures are illustrative. Build your own — the point is the structure, not the numbers.
Layer 3 — quantity adjustment. A per-unit component for cases, pallets or line items, added to the fixed component. service = fixed + (per_unit × quantity) fits most operations well and is easy to calibrate with a simple regression on your own history.
Keeping it honest
Service times drift. A customer moves their goods-in door, a store changes its receiving hours, a driver retires and their replacement takes four minutes longer. Build a monthly job that:
- Recomputes medians from the last 90 days.
- Flags customers whose median moved more than 25%.
- Flags customers where planned and actual diverge consistently in one direction.
- Pushes updates into the routing system automatically, with a review queue for large changes.
Operations that do this report their plan-versus-actual variance falling steadily for a year and then stabilising. Operations that set service times once at go-live see the opposite.
The organisational trap
Service time is often owned by nobody. Planning assumes operations maintains it; operations assumes it came with the software; the vendor assumes you configured it. Assign an owner explicitly, give them the monthly report, and make plan-versus-actual variance one of their measured objectives.
Common questions
What if I have no historical timestamp data?
Start with a two-week structured observation across your route types — a supervisor riding along with a clipboard is fine — then switch to telematics-derived measurement as soon as your app or trackers can supply arrival and departure events. Two weeks of real data beats any industry benchmark.
Should I use the mean or the median?
Median for planning, because long-tail outliers (a 90-minute wait at a hospital dock) would otherwise inflate every route. Use the 80th or 90th percentile separately to identify problem stops and to set buffers on time-critical routes.
How do I handle waiting time at the customer?
Model it separately if you can measure it. Waiting is a customer-caused cost, and separating it lets you have a commercial conversation about access rather than silently absorbing it into your route plan year after year.
Do time-of-day effects matter?
Yes, often substantially. The same store can take 8 minutes at 06:30 and 20 minutes at 11:00 when the aisles are busy. If your data supports it, model service time by time band for the segments where the effect is strongest.
What accuracy should I aim for?
Getting the route-level total within about 10% of actual is a reasonable target and enough to remove chronic overtime. Chasing per-stop precision beyond that is rarely worth the effort, since driving-time variability will dominate what remains.
