Drawing the daily route for a 5–30 van fleet — which van goes to which customer and at what time, so every delivery window holds (known in the literature as VRPTW).
In plain words
Sound familiar?
- The morning dispatch meeting — who goes where on which van — runs 1–2 hours every day
- When a customer's time window is missed, a second run goes out to redeliver
- Driver overtime hours come in 20–40% over plan at month-end
- The plan lives in a spreadsheet; one traffic jam or vehicle breakdown starts a phone chain
- There's a cold chain or time-critical delivery (milk, pharma, fresh produce); a missed window means the product is returned
- When a new customer is added, the question 'which van does this fit on' is settled by gut, not by a calculation
- A customer complained 'you keep arriving late' and moved their orders to another supplier
Why it matters
How it's solved
Technical depth
How it's solved
Technical depthOne-liner: Cluster customers in the same area asking for the same time-window onto one van and visit them back-to-back — empty kilometres and missed windows fall on the same decision. Same window, different neighbourhoods? Two vans is usually cheaper than one zig-zagging across town.
What the software is really doing is this: it takes the route you can build in your head for 30 customers and builds one for 200 in seconds. Three stages:
1. It collects the data. Customer addresses and time windows, the size or weight of each order, depot location, vehicle count and capacities, driver shift hours, average traffic speeds. The data is pulled automatically from the order system, or entered once into a structured table.
2. It finds the best route. The software does not try every possible sequence one by one — for 50 customers that is mathematically impossible (the combinatorial count is astronomical). Instead, it uses optimization — a technique from operations research (a discipline that uses math and computing to solve business-decision problems) — to take intelligent shortcuts: which customer goes on which van, in which order. A result comes back within seconds — for each van, an ordered list: “First stop A at 09:30, then B at 10:15, then C at 11:00, back to depot at 13:30.” The plan balances three goals at once: every window holds, total kilometers are minimized, and no van runs over capacity.
3. It lands on the driver’s tablet. The plan shows up as an ordered list in the driver’s mobile app, with built-in navigation and customer info. If traffic builds up or an extra order comes in, the software recomputes only the affected zone and a new route arrives in 10–30 seconds. If a vehicle breaks down, the software shows numerically which orders should be reassigned to which van.
It does not replace the dispatcher’s judgement; think of it as an error-free calculator that scales what they already do for 30 customers up to 200. The decision still belongs to the operator, but the plan is always current.
Alternatives
Spreadsheet + the dispatcher's head
FreeFree
Who it fits: 1–3 vans, 20–40 daily stops
- + Zero cost
- + Fully flexible — on-the-fly adjustments are easy
- + No capex decision
- − Plan quality drops fast past ~50 stops
- − Knowledge sits in one person — risk when they're off
- − Re-routing for traffic or window changes is slow with a paper map
- − No historical route records — you can't measure what worked
Local delivery management software
Enterprise$300–1,500 setup + $100–400/month (regional SMB pricing)
Who it fits: 5–20 vans, stable customer base
- + Local-language interface and support
- + Local maps and traffic data typically integrated
- + Driver mobile app included
- − Strict time windows and complex constraints (dual cold chain, multi-temp loads) often have limited support
- − Multi-depot or cross-docking scenarios can be weak
- − Algorithm transparency is limited — 'why this route' is hard to answer
International specialized routing software
Enterprise€100–500/vehicle/month subscription, or €50,000–250,000/year licence
Who it fits: 20–100 vans, multi-depot, cold chain, or heavily constrained delivery
- + Mature: multi-depot, capacity, windows, driver shifts all fully supported
- + Strong scenario comparison and simulation
- + Algorithms hardened over many years
- − High licence and consulting cost
- − Rollout takes 2–4 months
- − Local-language support can be limited
Custom build on an open-source solver
Open SourceLicence free; 6–12 weeks of internal development, or $40,000–150,000 of consulting
Who it fits: SMB with an in-house software team or strong technology partner
- + No licence cost
- + Fully customizable to your constraints
- + Runs in the cloud or on your own server
- − Requires internal technical capacity
- − Ongoing maintenance is real work
- − High risk for a team without routing experience
Recommendation
Ask in the meeting
- Do you support hard versus soft time windows? How is a missed-window penalty modeled in the objective?
- Do you support multi-depot, or mid-day vehicle reloads (cross-docking)?
- Can constraints like cold chain or mixed product types (frozen + dry on the same van) be defined?
- How are driver shift hours, legal break rules, and licence-class constraints entered?
- Where does your traffic data come from? How was regional accuracy validated?
- When a rush order arrives, how fast does the plan update? How does the new route reach the driver?
- How do you structure the pilot — how many vans, how many weeks, and what is the success bar?
- If we stop working with you, how do we get our customer and route data back? Is there a standard export format?
Technical details
Editor’s note
This problem is known on the dispatch desk as “route planning”, “delivery scheduling”, or “driver sequencing”. The academic name is Vehicle Routing Problem with Time Windows (VRPTW). The question you ask every morning — “which van, which customer, what time” — is the same one academia has worked on for decades. If you walk into a software demo without knowing that, you cannot tell whether the “routing module” being pitched actually solves time windows and capacity together.
The point most often overlooked in this segment: many products advertise “routing” but underneath they only run nearest-neighbor heuristics. That works reasonably for small problems; once windows are tight or capacities are tight, plan quality collapses. In any demo, ask the vendor to walk through a 20-stop example with 5 hard windows and 2 vans, and explain exactly which algorithm the engine uses.
A step-by-step path for an SMB
Stage 1 — Measure first, plan later. For at least four weeks, log four things in a spreadsheet:
- Kilometers and hours per van per day
- Number of window misses and their cause
- Number of half-empty return runs (van went out, half-loaded, but had to come back)
- Driver overtime hours
Without this baseline you cannot tell which software will deliver which result.
Stage 2 — Build the customer-window table. Write each customer’s accepted time windows in a single sheet. In most SMBs this lives only in someone’s head; writing it down alone delivers 5–10% efficiency. Split windows into “hard” (shop is open 09:00–12:00) and “soft” (morning preferred, but up to 16:00 is fine).
Stage 3 — Pilot. Start with 1–3 vans for 6–10 weeks. Define the success criterion in writing, before the pilot: e.g., “total kilometers down 10% and missed windows halved within 60 days.” If the bar is missed, the pilot ends — keep that exit right in the contract.
Stage 4 — Rollout. If the pilot lands, scale to the whole fleet over 2–4 months. Driver training runs 1–2 weeks; assign one “champion” driver per zone.
Risks — what can go wrong
- Bad address and window data. Wrong addresses poison the output. Clean the customer database first: coordinate verification, written window confirmation.
- Driver resistance. A driver who refuses to use a tablet can quietly sabotage the plan (“I went the old way again”). Find 1–2 volunteer drivers in the pilot; you can also turn experienced drivers’ tacit knowledge into explicit rules in the system.
- Traffic data quality. If the software’s traffic model does not reflect your city’s reality, computed travel times will be wrong. During the pilot, compare planned versus actual travel times.
- Vendor lock-in. Software that stores customer addresses and windows in a proprietary format makes it hard to migrate later. Put a clause in the contract: “We can export our data in standard open formats (CSV or similar) at any time, on request.”
Related cautionary lesson (will be linked once published): “A 9-month routing-software rollout that was abandoned in a local delivery fleet — what they missed.”
A technical view of the solution method
This section holds what you’ll need when talking to a software team or a consultant. It is not what the driver sees on a tablet — it is the engine behind the curtain.
The main approaches used for VRPTW:
| Approach | Typical scale | Solve time | Guarantees optimum? |
|---|---|---|---|
| MIP (mixed integer programming) | 20–100 stops | 1–15 minutes | Yes, given enough time |
| Column generation | 100–500 stops | 1–10 minutes | Practically near-optimal |
| Metaheuristic (tabu, ALNS) | 200–2,000 stops | 5–60 seconds | No (near-optimal) |
| Rolling horizon | Continuous flow | Instant | Practically acceptable |
In practice: under 200 stops, an open-source solver is enough. Above 500 stops, or for multi-depot delivery, commercial routing engines are typically preferred.
Objective function choice changes the shape of the solution:
- Total kilometers or fuel: “Minimize fuel and wear” — fits long-haul or fuel-heavy operations
- Vehicle count combined with kilometers: “Can I shrink the fleet?” — fits a capex decision
- Missed-window penalty: “Minimize customer-churn risk” — fits a contract-heavy customer base
Most real deployments use a weighted blend of all three.
Academic references
Listed in the sources block of this page’s frontmatter. INFORMS Interfaces and the European Journal of Operational Research archive carry deployment case studies tied to real fleets in transport and logistics.
Sources
- Toth, P. and Vigo, D. (2014). Vehicle Routing: Problems, Methods, and Applications (2nd ed.). SIAM. The standard reference text in the vehicle-routing field.
- Solomon, M. M. (1987). Algorithms for the vehicle routing and scheduling problems with time window constraints. Operations Research, Vol. 35 — the paper that introduced the benchmark instance set still used in VRPTW research.
- Cordeau, J.-F. et al. (2007). Vehicle routing. Handbooks in Operations Research and Management Science, Vol. 14.
- INFORMS Interfaces — case studies of operations research deployments in transportation and logistics. informs.org/Publications/Interfaces
Glossary
- VRP
- The decision of which vehicles, leaving from one or more depots, visit which customers in which order.
- Time Windows
- The hours in which a delivery or service can be performed — outside this window the visit is either refused or penalized.
- MIP
- An optimization model where some decision variables are forced to be whole numbers (e.g. number of trucks, number of shifts).
Related problems
From One Node to Another — How Do I Compute the Shortest Path on a Weighted Graph?
For SMBs that need to compute the fastest or shortest route between two points: 10-50-vehicle field-service teams (plumbing, electrical, appliance repair), urban courier/parcel operations, or dispatch centres coordinating emergency response. Every day brings hundreds of 'how do I get from A to B fastest right now' questions; the answer shifts with traffic, road closures and vehicle type. A wrong route costs the technician one or two jobs missed for the day, the courier a late delivery, and the firm a customer. Manual or by-eye routing typically leaves 20-60 wasted minutes per vehicle per day on the table compared with a network-aware route calculation.
Multiple Plants, Multiple Customers — How Much Does Each Plant Ship to Each Customer to Minimise Total Freight?
For food, packaging or textile producers shipping weekly from 3-8 plants or regional warehouses to 20-100 customers. The weekly decision is: which plant ships how much to which customer, given fixed plant capacities, stated customer demands, and a different per-unit cost (distance + vehicle + contract terms) for each plant-customer pair. The goal is the lowest total freight bill across the network. A 'nearest plant' or 'we've always done it this way' habit typically leaves 10-20% extra fuel and vehicle cost on the table compared with a systematic allocation.
One Vehicle, Many Stops — In What Order Should I Visit Them All to Minimize Total Distance?
You run a field technician visiting 8-15 customers a day (HVAC, lift servicing, white-goods repair), a single-vehicle supplier tour by a sales rep, or a PCB drilling machine sequencing 500-5,000 holes. All of them face the same core call: given N points, in what order should a single vehicle or head visit each one and return to the start. Get the order wrong and a field service vehicle burns 80-200 TRY/day extra in fuel and driver hours, a PCB line takes 15-30% longer per part, and the last customer of the day misses their delivery window. At 50 stops, a hand-built sequence runs 20-40% above the true minimum; as the number of stops grows, the gap from intuitive ordering compounds.