Service time: the minutes at the kerb that decide the plan
In short
Service time is everything between arriving at a stop and being able to drive away: parking, walking, waiting to be received, handing over, and recording it. A single fleet-wide default of 8 minutes is roughly right at a kerbside drop and wrong by half an hour at a gated receiving bay, so the plan fails at exactly the stops that were already tight.
Key takeaways
- Service time is not unloading. Parking, the walk and the queue at goods-in are usually the larger half.
- One default per fleet is the most damaging simplification in planning: the error is not random.
- The distribution has a long right tail. Plan tight-window stops at a high percentile, not the mean.
- You can measure it from tracking data without asking a driver to time anything.
- Where service time is wrong, dispatchers pad routes by hand, and the padding is the measurement.
Service time is every minute from the moment the vehicle reaches a stop to the moment it can pull away again. It is not the unloading. Unloading is usually the smallest component. The rest is finding somewhere legal to stop, walking, waiting for somebody to open a door, proving who you are, and recording what happened.
Almost every planning system accepts a per-stop value, and almost every deployment fills it with one number for the whole fleet because the real numbers were never collected. That default quietly decides how many stops fit in a shift.
Five things happening while the engine is off
- Stopping. Finding a legal, safe place to leave the vehicle, which depends on the vehicle — a long rigid cannot use the space a van uses, one of the operational effects of vehicle profiles, height, weight and turn bans.
- Walking. From the vehicle to the door, the bay or the security desk, then back again with an empty cage.
- Waiting. The queue at goods-in, the receiver who is on another aisle, the gate that is unstaffed. This is the component with no ceiling.
- Handing over. The actual transfer of goods, including checking counts against paperwork.
- Recording. Scanning, photographing, capturing a signature, and whatever the receiving site's own system requires on top.
Two stops, one parcel, and where the minutes actually go
| Component | Kerbside residential drop | Gated industrial receiving bay |
|---|---|---|
| Find a legal stopping place | 1 to 4 min, worse after 17:00 | 0 min, marshalled parking |
| Gate, security, sign-in | 0 min | 5 to 20 min, queue at one barrier |
| Walk to the door or bay | 1 to 2 min | 2 to 6 min across a yard |
| Wait to be received | 0 to 3 min, or a failed attempt | 10 to 45 min, goods-in runs its own queue |
| Handover and record | 1 to 2 min, scan and photo | 5 to 15 min, paperwork checked line by line |
| Secure and restart | 1 to 2 min | 3 to 8 min |
| Realistic total | 5 to 12 min | 25 to 90 min |
The two columns are the same parcel. Every difference is site design and receiving policy, not driver performance, which is why a fleet-wide average is not a compromise — it is wrong in both directions at once.
The average is wrong where it costs most
Service time is right-skewed. Most stops sit near the mode and a minority run several times longer, so the mean sits above the typical stop and far below the bad one. Planning at the mean means roughly half the stops overrun, and each overrun cascades into every stop after it.
This also interacts with enforcement. A stop whose window is hard and whose service time is understated by 15 minutes will make the plan look feasible and the day infeasible — see hard and soft time windows in a route plan.
Measuring it without asking drivers to hold a stopwatch
- Derive the stop interval from the position stream rather than from app taps. A stationary period near the stop location is the raw signal, and reading it correctly is the difference between a breadcrumb trail and the route line.
- Anchor both ends. Take the first fix inside the stop's zone as arrival and the first fix consistently outside it as departure, with the same confirmation logic used for arrivals generally.
- Attribute the interval to a stop archetype, not to a customer. Archetypes generalise to tomorrow's new customer; per-customer values do not exist until the second visit.
- Publish the distribution, not the mean. Give planners the median, the 80th percentile and the count behind each archetype, so a value built on 6 observations is visibly weaker than one built on 600.
Whether the engine can consume archetype-level distributions at all is a selection question rather than a configuration one, and it belongs with the other tests in licensing an optimiser versus writing one.
The dispatch desk has already priced these stops
Where service time is badly wrong, somebody is already correcting for it by hand: a dispatcher who moves a stop earlier every morning, or refuses to give one van more than 30 drops. Those overrides are the measurement, recorded in the wrong place — the argument in dispatchers rebuild the plan every morning.
Nobody plans a route badly on purpose. They plan it with one number for a thing that has never been the same twice.
Turning that correction into data is ordinary internal tools and operations work: a weekly job that recomputes archetype distributions and shows planners what moved. It is one piece of the routing, dispatch and optimisation layer inside the logistics systems it supports.
Frequently asked questions
Short answers to the follow-ups this page tends to raise.
What is service time in route planning?
It is the total time a vehicle is committed at a stop, from arriving to being able to leave, including parking, walking, waiting, handover and recording. Route solvers add it to travel time when checking whether a sequence fits the day, so understating it produces plans that are feasible on screen and impossible on the road.
Is service time the same as dwell time?
They usually mean the same interval but come from different systems. Dwell is what a tracking platform measures, from a geofence entry to an exit; service time is what a planner assumes before the day starts. Comparing the two is the whole calibration exercise, and a persistent gap between them is the fastest evidence that the planning default is wrong.
Should service time be fixed or vary with the drop size?
Split it into a fixed part and a variable part. The fixed part is parking, walking and sign-in, which barely changes with volume; the variable part scales with items, pallets or cages. A single flat value is defensible only where drops are uniform, which is rare outside a single-product round.
What service time should we use with no history at all?
Start with four archetypes rather than one number: kerbside residential, retail unit on a high street, warehouse receiving bay, and site with security control. Give each a value from a fortnight of tracking data if you have it, or from a supervisor who has driven the round, then replace the estimates archetype by archetype as observations arrive.
- route optimisation
- service time
- field operations
- planning data
The work behind this page
Builds from our portfolio that this page draws on.
Read next
- The travel-time matrix: the input that decides the planThe solver never sees a road. It sees a table of durations between every pair of stops, and every mistake in that table becomes a plan that cannot be driven.definition
- The optimiser made a plan and the desk rebuilt it by hand before eightSystematic override is not resistance to change. It is an unwritten requirements document being typed into your software every morning, one drag-and-drop at a time.diagnostic
- The plan came back complete and forty stops are not in itA solver that reports success while leaving forty stops unassigned is answering a different question from the one you asked. Relaxing one constraint family at a time tells you which.diagnostic
- The route crosses itself twice and the driver has already resequenced itA route that doubles back is either obeying a constraint the map cannot draw or genuinely bad. Only one of those is fixed by re-optimising; the other is fixed by explaining.diagnostic
- The solve still has not finished and the first van is loadedMost teams tune the solver and wait longer. In production systems the matrix is usually the slow half, and no search parameter touches it.diagnostic
- Vehicle profile: why a car route and a truck route are different networksA consumer navigation route given to a heavy vehicle is not a rough version of the right answer. It is a route through roads the vehicle is not allowed to use.definition
Working on something in this space?
Tell us where you are in a sentence or two. We'll tell you honestly whether we're the right team, and what a sensible first slice of the work looks like.
Start the conversation