In short: A narrow delivery window is a product with a cost, and that cost does not scale the way intuition suggests, since vehicle requirements rise sharply once windows tighten enough to break route continuity. A promise to a customer and a plan that delivers it are different objects, so a window agreed in a negotiation without a routing check reappears later as extra vehicles in a fleet budget with no line connecting the two. Putting a price on window width and letting customers choose usually shows that some of them would rather have the discount. Measuring the distribution of actual arrival times against the promised window, including the 95th percentile miss, shows whether a narrow window is a real capability or only a written one.
A national account negotiation gets to the last open point. The customer wants deliveries between eight and ten in the morning across sixty sites. The commercial team agrees, because it is the only thing standing between them and a signed contract, and because a delivery time is not the sort of thing anyone escalates.
Transport finds out at implementation. The region gets replanned around the new commitment, and the plan that came out with nine vehicles now needs twelve. Those three vehicles appear in next year's fleet budget as growth. No line anywhere connects them to the concession that created them, and when the contract comes up for renewal in three years the same concession will be made again for the same reason.
Narrow windows are a legitimate product and plenty of customers will happily pay for one. The trouble with this one is that it was given away by someone with no way to see what it cost, to a customer who was never asked whether they would rather have had a discount, and the price never got written down anywhere it could be found again.
Window width does not cost what you would expect
A routing solver builds an efficient day by clustering geographically and then travelling through the cluster in a sensible order. Time windows cut across that logic, because they impose an ordering that has nothing to do with where the stops are.
The structural point is about how fast feasibility disappears. On a nine hour operating day, a stop with a four hour window can legitimately sit in roughly the middle half of the route, so a large share of the other stops can precede it. Halve the window to two hours and the set of positions it can occupy roughly halves too, which means the set of feasible sequences the solver can search shrinks by much more than half, because sequences are combinations of positions. The solver ends up jumping between clusters to satisfy timing, and driving between clusters is expensive.
The second cost is waiting. A vehicle that arrives before a window opens sits there. If six stops on a thirty stop route involve twenty five minutes of waiting, that is 150 minutes of paid duty producing nothing, and in most regimes it counts against driving hours as well.
The third cost is the one that actually sets your fleet, and it is about concentration rather than width. Customer window preferences are not spread evenly across the day. Given a free choice, most ask for the morning. A business where seventy percent of narrow windows fall between eight and twelve is sizing its fleet against a four hour period and running half empty after lunch, and no amount of sequencing skill (X1) recovers that. The window policy is setting the fleet requirement, which makes it an input to the sizing decision (X3) rather than something to be absorbed by it.
Solomon's 1987 benchmark set for the vehicle routing problem with time windows was built to expose exactly this. The instance families vary window width and scheduling horizon over the same customer geographies, and the narrow-window, short-horizon families need substantially more vehicles than the wide-window ones to serve identical customers.
The way to get your own number is to run your own solver three times over the same week of real orders: once with day-level promises, once with four hour windows, once with two hour windows. Compare vehicle count and total duty hours across the three. The curve bends, and how sharply it bends is a property of your geography and your customers' preferences, which is why it has to be measured rather than assumed.
A promise and a plan are different objects
The window you give the customer and the window the routing engine plans against should not be the same width, and setting them equal is the most common reason on-time performance sits permanently in the eighties.
The plan produces a scheduled arrival time. Around that scheduled time there is uncertainty, from travel time variability and from service time variability at every preceding stop. That uncertainty accumulates along the route. The third stop of the day inherits two service times and two travel legs of variance; the twenty eighth inherits twenty seven of each. A uniform two hour promise applied to every stop is therefore too tight at the end of the route and too generous at the start.
Three things follow from that, and they are all cheap to implement.
Promise width can vary with position in the route, wider for stops served late in the day. Customers understand a two hour morning slot and a three hour afternoon slot better than they understand a two hour slot that misses.
Accounts that genuinely need precision can be scheduled early deliberately, which is a planning choice rather than a pricing one and it costs almost nothing.
And the promise should be derived from a calibrated interval rather than from a rule of thumb. Conformalized quantile regression gives a prediction interval with a coverage guarantee that holds out of sample, which is the property a promise needs and the property a fixed plus-or-minus buffer does not have. Validate it on held-out weeks with rolling origins, because an interval fitted and tested on the same period will look far tighter than it is.
If you are running dynamic ETA messaging to customers during the day, that is a re-promise, and it should be measured against the original commitment rather than against itself. A system that narrows its estimate at nine in the morning and hits it has still missed the window sold in the contract.
Put a price on the window and let customers choose
Attended home delivery has the most developed literature here, and it transfers to business delivery with very little modification. Agatz, Campbell, Fleischmann and Savelsbergh set out time slot management in Transportation Science in 2011, covering which slots to offer in which areas and how much the offer set is worth as a lever. Campbell and Savelsbergh had already shown in 2006 that incentives which steer customers toward slots fitting the existing route improve profitability. Klein and co-authors took it further in Transportation Science in 2019 with differentiated slot pricing that accounts for the routing cost of each slot.
In practice there are four instruments and most businesses use none of them.
A default wide window offered free. All day, or morning and afternoon. This has to be genuinely acceptable, or the pricing exercise turns into a tax rather than a choice.
A named narrow window at a stated price, either a per-drop fee or a service tier. In a business to business rate card this belongs alongside the tail lift charge and the booked-in charge, which is to say it is entirely normal and nobody finds it strange once it is written down.
Managed availability, where you show only the slots that are cheap to serve given what is already routed in that area on that day. This works where you cannot charge at all, which is most regulated and most heavily negotiated relationships.
Internal cost allocation, for the cases where neither price nor availability is available to you. Attribute the routing cost of narrow windows to the account's cost to serve, so the account P&L carries it and the account manager sees it before the next negotiation.
The revenue from window fees is usually small. What the price does is sort. Once a two hour window has a number next to it, a procurement team has to decide whether they want it, and a large share of them find that what they actually needed was a reliable day with an eight hour window, and that the narrow window was in the specification because someone copied a previous specification.
Self-scheduling changes who is responsible
Letting the customer pick their own slot does two things at once. It raises the probability that someone is there to receive the delivery, which is the dominant cause of failed attempts in home delivery and a meaningful one in business delivery to sites with limited receiving hours. And it moves the commitment from something you imposed to something they chose, which changes both the conversation when it goes wrong and the effort they put into being ready.
A failed delivery is expensive in a way that rarely gets fully counted: the wasted leg, the return to depot, the call handling, the stock sitting in transit for another cycle, the second attempt, and a measurable increase in the chance the customer looks elsewhere. Against that, the cost of giving the customer control of the slot is usually modest.
The catch is that self-scheduling hands demand shaping to the customer, which is what produced the eight to twelve concentration in the first place. So the offer set has to be managed rather than open: show the slots you want filled in that area on that day, hold back the ones that would break an existing route, and reopen them if the day fills differently than expected. That is the same lever as pricing, applied through availability.
Measuring the distribution of arrival times
Average lateness is close to a useless metric for a windowed operation. Twenty minutes early and twenty minutes late average to zero, and both are misses.
Four measurements are worth having, and they are all computable from data you already hold.
In-window rate. The share of deliveries arriving inside the promised window, with early arrivals counted as misses wherever the window is a real commitment. Unattended early arrival at a site with no one there is a failed delivery with a friendly name.
The tail. The 95th percentile of how far outside the window a miss falls, and the share of deliveries more than an hour out. A mean lateness of four minutes sits comfortably alongside eight percent of deliveries running forty minutes late, and it is the eight percent that generates every call.
Reliability by position in route. In-window rate at stop five against stop twenty five. If it degrades along the day, the promise width should vary along the day, and you have found the fix rather than just the problem.
Reliability by promised width. In-window rate on two hour promises against four hour ones. If the narrow promises are less reliable, you are selling a premium product that performs worse than the standard one, which is a commercial problem before it is an operational one.
A fifth measure is worth adding if you can build it: the share of accounts that experienced more than one miss in a quarter. Misses concentrate on the same accounts, because the same sites sit late in the same routes every week. A ninety four percent in-window rate spread evenly is a good service. The same rate concentrated on six percent of accounts every single week is a churn list.
The limit: the commitment is made before anyone can check it
None of this is an algorithmic problem. Window commitments get made in commercial negotiations by people who have no way to see the routing consequence, weeks or months before anyone in transport hears about it, and no solver recovers from a promise that was infeasible on the day it was agreed.
The fix is a sequencing change in the organisation. Any commercial commitment involving a delivery window passes a feasibility check before signature, and the check returns a cost per drop that goes into the deal margin like any other cost. The objection is that this slows deals down, and the objection is fair. The mitigation is to pre-compute the cost of the standard window offers by region and delivery pattern so that the check is a lookup for ninety percent of cases and a real study only for the genuinely unusual ones.
Two honest caveats. Some of these commitments are competitive necessities and you will take the cost anyway; knowing the number lets you choose where to spend it rather than discovering it in a fleet budget. And you cannot reprice contracts that are already signed, so the register you build now is a renewal tool with a lag of one contract cycle.
Start where the data already exists. Take last quarter's deliveries, group them by promised window width, and compute the in-window rate and the 95th percentile miss for each group; if your narrow windows are less reliable than your wide ones, you are selling a promise the plan does not support and the pricing conversation has an obvious opening.