Route Planning for Distributors: Constraints Generic Apps Miss
A driver leaves the depot at half past six with a van loaded the night before, a printed run sheet, and twenty-two drops to make before two o’clock. Three customers can only receive between nine and eleven; one needs a tail-lift for a pallet. By the time the van is on the road, the plan it follows has to hold up against the whole shape of the day, not just the distance between postcodes.
Generic delivery apps and consumer sat-nav do not see most of this. They see points on a map and a fast way to join them. For a courier dropping single parcels that may be enough. For a distributor running their own deliveries, the gap between “shortest sensible route” and “a route the day can actually be run against” is where the cost lives. The constraints that matter are not the road network; they are the orders, the vehicles, the windows, and the documents that travel with the goods.
The route starts with confirmed orders, not addresses
A consumer app begins with a list of destinations you hand it. A distributor’s day begins earlier, with the question of which orders are confirmed, which are on hold for credit, which are short on stock and will ship partial, and which were promised for today against a cut-off already passed.
Route generation is downstream of order management. The set of drops is whatever the order book resolved to overnight, filtered by what the warehouse can actually pick this morning. If a line is out of stock and the customer does not accept partials, that drop comes off the run; if a credit hold clears at eight, it goes back on. A planning tool that cannot read the live order state is planning against yesterday. Generic apps assume the list of stops is the input; for a wholesaler it is the output of everything between order entry and the pick face.
Windows, capacity and load are hard constraints, not preferences
Once the drops are known, the real work is fitting them to vans. A consumer router optimises one number: travel time. Wholesale delivery has several constraints that all have to hold at once, and a route that wins on distance can lose on every other count.
- Delivery windows. Many trade and retail customers receive only at set times: a pub before opening, a school kitchen between breakfast and lunch, a supermarket back door that turns away anything early or late. Miss the window and the drop fails, the goods come back, and the run was longer for nothing.
- Vehicle capacity. A van has a weight limit and a volume limit, and the two rarely run out together. Bottled water hits weight long before it fills the space; empty packaging fills the space at almost no weight. The planner has to respect whichever ceiling the day’s mix hits first, per vehicle.
- Load and handling. Chilled goods cannot ride with ambient on a van with no partition. A pallet drop needs a tail-lift. Some customers cannot take an artic down their street. Heavy items want loading last and dropping first, so the driver is not unloading a tonne to reach a box at the back.
The route has to be feasible before it is fast, and feasibility is the product of windows, weight, volume and handling, checked against the vehicles on the yard.
Clustering for the trade is about service, not just proximity
Geographic clustering sounds like the part a generic tool should do well, and at the level of “group nearby stops” it does. The difference for a distributor is what “nearby” is allowed to override.
Two customers a mile apart might belong on different runs because one needs a morning window and the other an afternoon one, and putting them together would force the van to wait or backtrack. A customer on the edge of one cluster might sit better on the neighbouring run because it already has a vehicle with the right handling kit. Clustering for the trade holds the service constraints steady and groups around them, rather than grouping on distance and hoping the windows follow.
There is also the matter of who the customer is. A key account that expects the same driver and a consistent delivery time is not a pin to be reshuffled every morning for a marginal mileage saving. Round consistency has a value a pure distance optimiser will quietly destroy, and the planning has to let the operation protect the accounts that need it.
This is the work our SFA and logistics module is built around: generating daily runs from the live order book while respecting windows, vehicle capability and the accounts that need a steady round, not distance in isolation.
Re-planning when orders change late
The plan made at six is rarely the plan that runs. A customer calls at quarter to seven to add two cases. Another cancels. A promised pallet did not come in on the inbound load, so a drop slips to tomorrow. Stock counted as available is damaged at the pick face.
For a courier, a late change means one parcel moves. For a distributor, it can break the feasibility of a whole run: the added cases push the van over weight, or the cancelled drop was the one that justified sending a vehicle to that corner of the territory. Re-planning is a daily event, not a rare exception.
The practical test is not how good the first plan looks. It is how the tool behaves at twenty past seven when three things have changed and the first vans are pulling out. Can it re-fit the affected drops without disturbing the runs already committed and loaded? A tool that can only generate from scratch forces a choice between a stale plan and a chaotic one.
Documents, proof and exceptions are part of the route
A delivery is not finished when the van reaches the address. It is finished when the goods are signed for, the paperwork matches what was handed over, and any shortfall or refusal is recorded in a way the office can act on.
Wholesale deliveries carry documents the consumer world does not: a delivery note that has to match the order, sometimes an invoice travelling with the goods, lot or batch numbers where the product demands traceability, return notes for empties or rejected stock. The dispatch step has to produce the right paper, or its electronic equivalent, for each drop, reflecting the order as shipped.
Proof of delivery closes the loop back to the business: a signature, a name, a timestamp, a photo where it helps. And, critically, a clean way to record what did not happen — the customer refused two cases as over-ordered, the back door was locked, the pallet was damaged in transit. These exceptions drive credits, re-deliveries and the next day’s plan. A generic app that ends at “marked delivered” leaves the most expensive part of the day undocumented.
Frequently asked questions
Why is a consumer sat-nav not enough for delivery rounds?
A sat-nav optimises travel time between points you give it. It has no view of delivery windows, vehicle weight and volume limits, handling requirements, or which orders are even confirmed. For a wholesale round, the route has to be feasible against all of those before speed matters.
How do you handle orders that change after the run is planned?
By treating re-planning as routine. When a drop is added, cancelled or shorted, the affected runs are re-checked for capacity and window feasibility and re-fitted, without disturbing runs already loaded and committed.
What counts as proof of delivery for a distributor?
More than a “delivered” tick. It is a confirmation tied to the specific drop, the document that matches what actually shipped, and a recorded outcome for anything that went wrong: a partial acceptance, a refusal, a damaged item, a failed window. That record feeds credits, re-deliveries and the next day’s planning.
Route planning for a distributor is not a map problem with some logistics attached. It is a logistics problem that happens to involve a map. The constraints generic apps miss — confirmed orders, windows, capacity, handling, round consistency, late changes, and the documents that close the loop — are the substance of running your own deliveries well. Software that starts from the order book and the vehicles on the yard fits the way the work is done.
T.R.