Delivery Window Planning: Build Routes Around the Customer Promise

A delivery window is a customer promise expressed as a planning constraint. If a site expects the van between 09:00 and 10:30, putting that stop on a route that reaches the area at noon does not become a good plan because the total mileage is low. Delivery window planning starts by making the promise explicit, then testing whether the route can satisfy it alongside the rest of the day.

The practical job is to separate three things that are often mixed together: the customer's agreed window, the time the stop realistically takes, and the constraints that decide which vehicle or driver can serve it. Once those inputs are visible, optimisation becomes useful. Before that, it can only optimise the assumptions it has been given.

Put one difficult route on the table

A customer account can have several delivery points, and those sites can operate differently. One branch may accept goods from 07:00; another may not open the receiving bay until 10:00. Treating the customer as one timing rule loses the detail the planner actually needs.

For each delivery point, hold the window as structured data rather than a note in a route planner's head. Add the expected service time and any operational constraint that genuinely affects allocation. The route can then be tested against the real promise instead of a generic “morning” label.

Check the promise before the route

Many planning problems are really data problems. A two-hour window copied from an old spreadsheet may no longer reflect the receiving hours. A nominal five-minute stop may take twenty when the customer requires a goods-in check. A route can look late because the plan was built on the wrong assumptions before the van ever left.

If the day is impossible, make the conflict visible

A useful route planner does not make every stop fit by quietly breaking the customer promise. When delivery windows or required vehicle skills are treated as hard constraints, a stop that cannot be placed should be surfaced as a planning problem.

That is valuable because it moves the conversation from “the optimiser gave us a bad route” to the actual decision. Perhaps one window can be renegotiated. Perhaps a second vehicle is needed for that day. Perhaps a fixed stop should move to another route. Perhaps the workload is simply too high for the available hours. The planner still needs to make that commercial or operational choice; the software should make the conflict visible early enough to act on it.

Change one assumption at a time

Once an infeasible stop appears, work through the decision in a fixed order instead of manually dragging stops until the map looks better.

1. Check the data first. Confirm the delivery window, service time and site address before changing the route.
2. Check the allocation. See whether another suitable route or vehicle can absorb the stop without breaking its own constraints.
3. Check the promise. If the window itself is negotiable, agree the change with the customer rather than treating lateness as the new normal.
4. Check the capacity of the day. If the workload cannot fit, add capacity, move work to another day where appropriate, or remove a non-essential constraint.

The important part is that each change has an owner. The transport team owns route capacity; the account team may own a customer-window conversation; the master-data owner updates the delivery point once a new agreement is made.

When the capacity question becomes commercial, pair the route review with the true cost-per-drop method rather than deciding from drop count alone.

Service time is part of the promise

A two-hour customer window does not mean the planner has two free hours. The stop itself consumes time, and that time affects every ETA that follows. If a school kitchen needs ten minutes for a straightforward handover and a hotel goods-in routinely requires a longer check, planning both as the same nominal stop duration will distort the rest of the route.

Use service time as a planning input, then review it against actual operations. Do not chase minute-perfect averages. Look for stops where the planned duration is obviously out of line with the work: multi-drop sites, access-controlled premises, customers with detailed checks, or stops that combine delivery with returns and collections. Correcting a handful of large mismatches can make the route more realistic without turning the master-data exercise into a time-and-motion study.

If service time is the constraint you are trying to quantify, the same arrival-to-departure evidence feeds a drops-per-van and route-density benchmark. That helps separate a timing-data problem from a genuine capacity problem.

The same principle applies when one customer has several sites. Link each order to the correct delivery point rather than relying on a customer-level note, because the window, access and service pattern can differ by location. The order-management record should feed the route with the site that is actually receiving the goods.

Audit a sample of stops, not the whole network

You do not need to rebuild every route at once. Pick one route with enough timing pressure to make the exercise useful and review twenty stops. The aim is to find the gap between the window in the system and the window the operation is actually working to.

After the audit, re-plan the route with the corrected inputs. The useful result is not a theoretical percentage improvement. It is a plan in which the timing assumptions are now explicit and the remaining infeasible stops are visible enough to resolve.

Keep one-off exceptions out of master data

Temporary changes deserve their own handling. A customer may ask for an earlier delivery during a refurbishment, a one-off event or a stocktake week. If the planner overwrites the permanent delivery window to make that single day work, the exception can quietly become the new master data.

It is also worth separating a planning conflict from a delivery failure after dispatch. The latter belongs in the wider delivery-exception review, where shorts, refusals and redeliveries are measured as outcomes rather than planning inputs.

Use a simple control: distinguish the normal site window from the exception for this order or route. Record who agreed the temporary change and when the normal rule resumes. After the route is complete, the delivery point should still contain the standing promise unless the customer has genuinely changed it.

This matters for seasonal distributors as well. A site can have a different operating pattern during Christmas, school holidays or summer trading. If the change repeats predictably, treat it as a planned seasonal rule in your operating calendar. If it is genuinely one-off, keep it out of the permanent delivery-point record.

Review the stop the customer experiences

Average route performance can hide a repeated miss at one difficult site. When reviewing delivery-window planning, look at the delivery point as well as the route. A route can be broadly on plan while the same early-window customer is consistently late because the sequence or service-time assumption is wrong.

Use route history to compare the planned ETA with the actual visit pattern, then ask whether the miss is caused by planning data, a recurring operational constraint or an event outside the plan. Do not turn every late visit into a permanent window change. The purpose of the review is to improve the assumption that is actually wrong.

What RouteMagic exposes before dispatch

In RouteMagic, a customer can have multiple Delivery Points, each with its own delivery window and settings. The Route Planner assigns confirmed orders to vehicles and drivers, sequences stops and checks estimated arrival times against those delivery windows.

Route optimisation can respect time windows and vehicle skills as hard constraints. Pinned stops are not moved, and a stop that cannot be placed under the active constraints is flagged as infeasible rather than silently dropped. Weight and volume capacity can also be included where the relevant company settings are enabled.

During the day, Route Monitor provides the live operational view of driver positions and stop status; Route History provides the same route picture afterwards for review. That combination lets the team separate planning quality from what actually happened on the road without claiming that a window alone guarantees an on-time delivery.

Conclusion

Good delivery window planning is less about drawing a clever route and more about making the customer promise usable by the planner. Capture the window at the delivery point, use a realistic service time, add only the constraints that genuinely bind the stop and let the planning process expose what cannot fit. When a route is infeasible, fix the cause deliberately: correct bad master data, reallocate the stop, change capacity or agree a different promise with the customer. A useful first step is a twenty-stop audit on one pressured route. Compare what the system says with what the sites actually require, correct the inputs and re-plan. The route may still contain difficult choices, but those choices will now be visible before the driver leaves the depot. That is the point of delivery window planning: turn timing from tribal knowledge into a constraint the operation can actually manage.