Every commercial team wants narrower delivery windows. Every operations team knows what they cost. The argument usually gets settled by whoever is louder, when it should be settled by a number.
Why narrow windows are expensive
A time window is a constraint that removes options from the optimiser. With no windows, the engine can sequence purely for efficiency. With a two-hour window on every stop, it must fit each visit into a specific slot, which forces:
- More vehicles to cover overlapping demand peaks
- More empty running between geographically distant stops that happen to share a slot
- More waiting time when a vehicle arrives early and cannot deliver
- Lower stops per hour, because the sequence is no longer free to be efficient
The cost curve is non-linear. Going from all-day to a four-hour window is usually cheap. Going from four hours to two roughly doubles the penalty. Going from two hours to one can double it again, because at that point the window is often shorter than the travel time between consecutive customers.
| Window policy | Typical efficiency impact vs all-day |
|---|---|
| All day | Baseline |
| AM / PM half day | 2–6% more route hours |
| 4-hour window | 5–12% |
| 2-hour window | 12–25% |
| 1-hour window | 25–45% |
| 30-minute window | Usually needs a dedicated model |
These ranges assume the same customer base and geography. Your figures will differ; the shape of the curve will not.
For each customer segment: what actually happens if we arrive 45 minutes late? If the answer is "nothing", the window is soft.
Hard windows, soft windows and what your software does with them
- A hard window is a constraint. Violating it makes the plan infeasible; the optimiser will add a vehicle rather than break it.
- A soft window carries a penalty. The engine may violate it if the alternative costs more than the penalty.
Most operations should use soft windows with meaningful penalties for the majority of customers, and hard windows only where violation genuinely fails the delivery — a store that physically cannot receive outside its hours, a hospital dock with a booking system, a timed-slot contract with a penalty clause.
Configuring everything as hard is the most common misconfiguration in delivery routing. It produces plans that require more vehicles than you own, planners overriding the system daily, and eventually abandonment of the tool.
Designing a slot policy
Segment your customers. Not everyone needs the same promise. A typical structure:
| Segment | Window offered | Rationale |
|---|---|---|
| Contracted key accounts | Booked slot, 1–2 h | Contractual, priced in |
| Standard commercial | 4 h, chosen by us | Efficiency preserved |
| Residential premium | 2 h, customer chooses | Priced as an upgrade |
| Residential standard | All day, ETA on the day | Cheapest to serve |
Price the difference. If a two-hour window costs you 15% more route hours, that has a price. Businesses that give narrow windows away for free are subsidising the customers who care least about price with margin from those who care most.
Use dynamic slot availability. The strongest pattern in consumer delivery: at the point of booking, offer only the slots that fit the emerging route economically, and price them accordingly. This requires the routing engine to be callable during order capture, which is a real integration requirement worth confirming before purchase.
Communicate a narrowing ETA instead of a narrow window. Promise a four-hour window at order time, send a one-hour ETA the evening before, and a live 15-minute ETA on the day. Customer satisfaction research consistently shows this is nearly as good as a narrow booked slot, and it costs a fraction as much because the plan stays free.
Measuring window performance
Track, per segment:
- Window compliance rate — deliveries inside the promised window
- Mean lateness and P90 lateness for the misses
- Early arrivals and waiting time, which is pure waste
- Redelivery rate caused by window failure
- Cost per stop by window width, which is the number your commercial team needs to see
If you cannot produce the last line, you cannot have a rational conversation about windows. Building it is usually a day's work with plan-versus-actual data.
Common failure patterns
Everyone gets the tightest window. A single policy applied uniformly, usually inherited from the largest customer's contract.
Windows set by sales at the point of sale, with no capacity check, then thrown over the wall to planning.
Windows recorded as preferences but enforced as constraints — the customer once mentioned mornings were easier, a planner recorded it, and three years later the optimiser is treating it as law.
No expiry on special arrangements. Review customer-specific windows annually; a surprising share exist because of a manager who left in 2019.
Common questions
What window width should we offer?
Start from what customers actually need rather than what competitors advertise. Survey a sample: many commercial customers care far more about a reliable ETA and a consistent driver than about the width of the window. Then price anything narrower than your standard.
How do I convince sales that windows cost money?
Produce cost per stop by window width from your own plan-versus-actual data, and show the vehicle count needed to serve the same customers under different policies. Scenario comparisons in the routing tool are persuasive precisely because they use your own numbers.
Should the window apply to arrival or to completion?
Define it explicitly, because vendors differ and it changes the plan. Arrival-based is the norm in delivery. Completion-based matters where service time is long — a 90-minute install starting at 16:55 inside a "by 17:00" window will not feel compliant to the customer.
Can we mix booked slots and unbooked work on the same route?
Yes, and it is often the most efficient structure: booked slots form fixed anchors and flexible work fills the gaps. It requires an engine that handles pinned stops well, which is worth testing explicitly in a demo.
What about failed deliveries caused by the customer being absent?
Track them separately from window failures. Absence is a communication problem — solved by reliable notifications and access instructions — while window failure is a planning problem. Conflating them hides which one you actually have.
