Short answer. Data first: every order has a geocoded address with its zone, an optional window, a weight and volume; every vehicle has a capacity and a departure time. A routing engine, open-source software installed on the server with OpenStreetMap maps, computes a travel-time matrix between all pairs of stops and proposes a near-optimal order; the problem is known to have no fast exact solution, and an order close to the best is enough. The plan is computed the evening before at 18:00: group by zone, check each group’s load, order the stops, check that each stop’s planned time fits its window; the planner can move a stop by hand, and the plan recomputes the times of all following stops. The driver application shows the round in order, offline, and timestamps arrival and departure at each stop, with proof of delivery and exceptions. The day compares planned and actual; a breakdown or a refusal triggers re-planning in minutes, with a message to the moved customers. And today’s actual, times per zone and per stop, corrects tomorrow’s plan.
This guide is for the distributor and the wholesaler delivering to retailers with their own vans, the delivery company that wants a computed round rather than a memorised one, the online shop delivering itself in its city, and the founder based in France who wants to read kilometres, stops per hour and windows met in the evening. It does not repeat how to deliver without an address nor how to build the courier application with proof of delivery and cash on delivery, described in the no-address delivery guide and the delivery platform guide; it describes what those two guides lack: the computation of the round itself, and it extends our software engineering page.
Round planning, in five layers
The routing engine is the accented layer: it replaces the driver’s memory with real times between all addresses.
Data. Addresses are geocoded and attached to a delivery zone, following the no-address delivery guide; every order carries its optional window, its weight and volume, computed from the product record’s packagings; every vehicle carries its capacity, departure time and depot. Routing engine. Open-source routing software, installed on the server with the region’s OpenStreetMap maps, exposes two services: according to its public documentation, the table computes the duration of the fastest route between all pairs of supplied coordinates, and the trip solves the visiting order with a heuristic, that is, an order close to the best, not guaranteed optimal, because the underlying problem, the travelling salesman, has no fast exact solution. For three vans, the application first groups by zone, then asks for an order per group.
Plan. Zones, load, order, windows; computed the evening before at 18:00 by a job of the background jobs guide; every plan is dated and kept, never overwritten, to compare planned and actual. Driver application. Round in order, offline by construction following the offline guide; timestamped arrival and departure per stop; proof of delivery following the trustworthy photos guide; exceptions with reason. Day and measurement. Deviation tracking, re-planning, messages to moved customers; stops per hour, kilometres per stop, windows met, and feeding real times back into the next plan. The engine runs on the company’s server or at the host chosen in the hosting guide; no customer address leaves for a third party.
Tuesday’s 38 stops in three vans
The figure follows one Tuesday’s plan: thirty-eight stops, three vans, four computation steps.
Group by zone: the thirty-eight stops fall into three neighbouring zones, West, Centre, East; a zone that is too heavy hands a border stop to its neighbour. Check the load: van B is at 1,180 kilos of 1,200, and the plan says so; a group above capacity moves a stop the evening before, not at loading. Order the stops: for each group, the travel-time matrix is requested from the engine, one request for a dozen stops, and the proposed order follows; the one-way street and the bridge count, not straight-line distance. Check the windows: each stop’s planned time is computed from the departure time, the travel times and a service time per stop; a missed window adjusts the order or triggers an alert to the planner.
The result: A, twelve stops, 46 kilometres, planned return 12:50; B, twelve stops, 38 kilometres, a tight window at stop 3 with eight minutes of margin; C, fourteen stops, 52 kilometres. The planner sees all of it the evening before at 18:00, can move a stop by hand, and the application recomputes the times of all following stops and says so. The next day, every driver sees their round in order on their phone, and the sick driver’s replacement follows the same one. Stops, loads, kilometres and times are a constructed example.
«The stop order comes from a travel-time matrix between all pairs of addresses, not from straight-line distance nor from the driver’s memory.»
The driver’s day, in six beats
The driver application is what turns a plan into a measured actual. It works offline in the stairwell.
Load: each parcel is scanned at loading, and a missing or extra parcel is seen at the depot, not at the customer’s, following the movements of the stock guide. Leave: the round in order, with planned times, is on the phone before leaving the depot’s network. Arrive: arrival is timestamped by the application, and the driver can call or message the customer from the application, through the channel of the notifications guide; it is the accented beat, because that arrival-departure pair per stop is the day’s only true measure.
Deliver: scan, photo, signature or code, cash entered if cash on delivery, as in the delivery platform guide. Report: absent, refused, address not found, with a reason chosen from a list, a photo, and a new attempt planned. Return: returns are scanned at the depot, and the planned-vs-actual gap per stop enters the evening review. For the cold chain, the temperature at opening is added to the same stop, following the cold chain guide.
Six real situations, and what the application does
Every row is a sentence heard at a distributor, and the answer is a computation, not a more experienced driver.
The van drives through the same neighbourhood again: zones then order by travel time bring, in the example, 70 kilometres down to 46 for the same work; the measure is kilometres per stop. The customer required before 10:00: the window is on the order, the planned time is checked the evening before, and the plan places it early or alerts. A van breaks down: re-planning in minutes, stops redistributed, customers warned before the time.
The driver “knows” the city: the order is computed and shown, and the replacement follows the same round; the driver’s knowledge serves to correct the plan, not to replace it. Too many parcels for the vehicle: the load is checked in the plan, and the stop is moved the evening before. Nobody knows where the round is: timestamped arrivals give a recomputed planned time per stop, visible to the manager and sent to the customer; the rep of the pre-sales guide sees the same for their customers.
The real day: breakdown at 10:40, six stops move
The figure follows the same Tuesday for real. The evening plan is a hypothesis, and the day corrects it.
At 10:40, van B breaks down, six of twelve stops done. The planner opens the remaining six: their positions, their weights, the current positions of A and C and the travel times are already known. In four minutes, three stops go to A, which will finish an hour later, and three to C; the plan recomputes the planned times of all following stops of both vans. At 10:44, the six moved customers receive the new planned time through the channel of the notifications guide, with a possible reply: four confirm, one postpones to tomorrow, one does not reply and the planner calls at 11:00. An agent built as in the WhatsApp agent guide can hold that exchange, never the redistribution.
Result: everything is delivered, the last return is at 14:20 instead of 13:10, and two windows are missed with warning before the time. In the evening, the actual is written stop by stop; the review shows the deviations, and real times per zone replace the estimates in next week’s plan. Three figures go to the manager’s dashboard: stops per hour, kilometres per stop, windows met, each with a single definition. Times, stops and messages are a constructed example.
«Redistributing six stops takes four minutes because loads, positions and travel times are already known; by hand, it is an hour on the phone.»
Planning rounds in 2027, in weeks
Seven weeks, the first without code, and two for the plan, because it is what the manager sees every evening.
- What the manager sees: tomorrow’s plan at 18:00, load and windows checked; the current day, stop by stop; three figures in the evening.
- What the driver no longer does: choose the order, declare times in the evening, call the depot to know where to go after a breakdown.
- What is measured: stops per hour, kilometres per stop, windows met, first-attempt deliveries, real times per zone.
Week 1, rules: vehicles and capacities, departure time, zones, customer windows, service time per stop, exception reasons; with the manager and the operations lead. Week 2, data and engine: geocoded addresses, weight and volume per order, routing engine installed with maps, time matrix tested on a real round from last week, to compare its times with the lived ones. Weeks 3 and 4, plan: zones, load, order, windows, planner screen, hand edits with recompute, evening plan at 18:00.
Week 5, driver application: offline round, timestamped arrival and departure, proof of delivery, exceptions, returns, reusing what already exists. Week 6, day: deviation tracking, re-planning, messages to moved customers, evening review. Week 7, measurement: stops per hour, kilometres per stop, windows met, first-attempt deliveries, and feeding real times back. Going live follows the application delivery guide: one van the first week, the others after, the evening plan compared with the real round before the notebook is retired.
- Is a paid maps service needed?
- Not necessarily. The routing engine is open-source software installed on the company’s server, with the region’s OpenStreetMap maps; it computes the travel-time matrix and the visiting order without sending customer addresses to a third party. The quality of local maps is checked in the second week on a real round.
- Is the stop order optimal?
- Close to the best, not guaranteed optimal: the underlying problem, the travelling salesman, has no fast exact solution, and the engine uses a heuristic beyond about ten stops, according to its documentation. In practice, what counts is the gap with the order in which orders arrived, measured in kilometres per stop.
- And customer windows?
- They are on the order. The plan computes each stop’s planned time from the departure time, travel times and service time, and checks that it fits the window; otherwise the order is adjusted or the planner is alerted the evening before.
- What happens when a van breaks down?
- The remaining stops are redistributed within minutes to the other vehicles, because loads, positions and travel times are known; planned times are recomputed and the moved customers receive a message with a possible reply.
- Can the driver change the order?
- Yes, and it is desirable when they know something the map does not: a market blocking a street, a customer closed on Tuesdays. The change is recorded, planned times are recomputed, and the deviation appears in the evening review, to correct the next plan.
- Does it work without network?
- The driver application, yes: the round, planned times and proof of delivery work offline and sync when the network returns. Plan computation and re-planning happen on the server, at the depot or from the planner’s phone.
- How long to set this up?
- Seven weeks in the typical calendar, the first without code and two for the plan. A company that already has the courier application and geocoded addresses takes less; one starting from paper notes and free-text addresses takes all seven.