Route optimization is the process of computing the most efficient sequence of stops for a vehicle (or a fleet) given time windows, vehicle constraints, road network conditions, and a cost objective — typically a weighted mix of distance, time, fuel, and emissions. It is what separates a fleet that runs 1.5 stops per hour from one that runs 2.4.
This guide explains what route optimization actually computes, how the underlying algorithms work, what kind of savings to realistically expect, where the technology breaks down, and how to evaluate route optimization software for your operation. Written for transport planners, logistics managers, and IT teams choosing between vendors.
In this guide
- What route optimization actually is
- The five inputs every route optimization engine needs
- How the algorithm works (briefly)
- What savings to expect — and where the numbers come from
- Static vs real-time (dynamic) routing
- Multi-stop routing and the Vehicle Routing Problem
- Where route optimization breaks down
- How to evaluate route optimization software
What route optimization actually is
The simplest version is the classical Travelling Salesman Problem (TSP): given a set of stops, find the shortest sequence that visits each exactly once. Route optimization in logistics is TSP with constraints. Every additional constraint — time windows, driver hours, vehicle capacity, dangerous-goods compatibility, customer service level — narrows the feasible set and changes which sequence is "best".
A useful working definition: route optimization is the computation of stop sequences and vehicle assignments that minimise a cost function subject to a defined set of operational constraints, recomputed at a frequency that matches the volatility of the operation.
That last clause matters. A grocery distributor whose drops are fixed by 18:00 the day before runs once-daily optimization. A last-mile courier whose drops change minute-by-minute as new orders land needs dynamic optimization that recomputes on every event. Choosing the wrong frequency wastes money: too rare and you miss real-time savings; too frequent and you destabilise the driver's plan.
The five inputs every route optimization engine needs
- Stops with addresses (geocoded to lat/long), service durations (how long the driver stops), and time windows (earliest and latest acceptable arrival).
- Vehicles with capacity (weight, volume, pallet positions, ADR class), shift windows, base location, and capability flags (tail-lift, ATP-certified for refrigerated cargo, height/weight restrictions).
- Drivers with start/end times, certifications (CMR-trained, ADR-certified), and remaining driver-hours under EU Regulation 561/2006.
- Network data: road network, travel times (ideally historical and traffic-aware), speed restrictions, toll roads, low-emission zones, and access restrictions for HGVs.
- Objective function: the weights on distance, time, cost, CO₂, and SLA penalties. This is the most underspecified input — most operators don't have an explicit one and let the software default.
Without all five, the optimizer can still produce a plan, but the plan won't reflect the operational reality. Real-world failure modes are almost always missing-constraint bugs: a truck routed under a 3.5 t bridge, a driver assigned a 12-hour day, a refrigerated load on a non-ATP trailer. Garbage in, plausible-looking garbage out.
How the algorithm works (briefly)
Exact methods (branch-and-cut, dynamic programming) solve small instances to provable optimality but explode combinatorially. A 50-stop TSP has roughly 3 × 10⁶² possible sequences. A 100-stop VRP with 10 vehicles is intractable for any exact solver in real-world time budgets.
Production route optimization therefore uses metaheuristics that find very-good (not provably optimal) solutions quickly. Three families dominate:
- Construction heuristics build an initial feasible solution one decision at a time. Greedy insertion, savings algorithm (Clarke-Wright), nearest neighbour. Fast but rarely competitive on their own.
- Local search takes a feasible solution and improves it by swapping adjacent stops, reversing segments, moving stops between routes. 2-opt, 3-opt, or-opt, large neighbourhood search (LNS).
- Population-based methods maintain a set of candidate solutions and combine them — genetic algorithms, ant colony, scatter search. Effective on very large instances but sensitive to tuning.
Modern commercial engines (Google OR-Tools, Jsprit, vroom, Routific, and the engines inside platforms like Transportial) combine construction + LNS with rich constraint handling, exposed through an API that accepts the five inputs above and returns a plan within seconds for problem sizes up to a few thousand stops.
What savings to expect — and where the numbers come from
Vendor case studies routinely promise 15–30% reduction in distance, 10–25% in cost, 20%+ in CO₂. Treat the upper end of those ranges sceptically. They typically compare optimized routes against either spreadsheet planning or no planning at all.
A realistic decomposition for an operator already running a competent manual planner:
- 5–10% distance reduction from better stop sequencing within trips that were roughly correct to begin with.
- 10–15% additional stops per shift from cleaner allocation — vehicles aren't idle waiting for time windows and drivers aren't doing 30-minute deadheads back to depot.
- 20–30% planner time reduction, which compounds into the ability to onboard new customers without hiring planners proportionally.
- 5–8% fuel reduction, mostly from the distance saving but with a kicker from reduced idling at customer sites with tight time windows.
The cost savings are real but the planner-time saving is usually the bigger commercial story. A planner is €60k+ per year fully loaded; software that lets one planner do the work of 1.5 frees substantial margin without operational risk.
Static vs real-time (dynamic) routing
Static routing computes plans once — typically the day before, against the full set of known orders. It is the right model for fleets where the order book is closed 12+ hours before the operational day starts (grocery distribution, scheduled deliveries to fixed customers).
Dynamic (real-time) routing recomputes as new orders arrive, drivers fall behind, traffic shifts, or stops cancel. The optimizer runs continuously and updates the plan in flight. This is the right model for same-day delivery, courier networks, urban last-mile, and any operation where orders land throughout the day.
The technical trade-off is plan stability. A purely greedy real-time optimizer will reassign drivers every few minutes, which drivers (correctly) hate. Production dynamic engines therefore add a change cost to the objective function: a new plan must be measurably better than the current one to be applied, and stops already actioned by the driver are frozen. Done well, the driver sees a sensible, infrequently-updated plan; the planner sees an automatically-stabilised operation.
Multi-stop routing and the Vehicle Routing Problem
Multi-stop routing is the Vehicle Routing Problem with Time Windows (VRPTW): a fleet of vehicles serving many customers, each with their own delivery window, returning to a depot. Variants extend it: pickup-and-delivery, multi-depot, heterogeneous fleet, electric vehicles with charge state. The literature is huge; the OR-Tools documentation is a practical starting point for the constraint vocabulary.
In a transport platform, multi-stop routing typically integrates with the planning UI as a "suggest plan" button. The planner sets the day's available drivers and vehicles, the system computes proposed allocations against the open order book, and the planner approves, edits, or rejects per trip. Auto-applying optimizer output without human review is technically possible but rarely deployed — exception-handling experience is hard to encode and the cost of a single wrong allocation (missed delivery to a key account) outweighs the marginal gain from full automation.
Where route optimization breaks down
Three failure modes are worth knowing before you procure:
- Missing constraints. If your operation has rules nobody wrote down — "we never put Driver X with Customer Y", "this truck has to be back by 17:30 because of the workshop" — the optimizer will violate them and the planner will lose confidence. Spend the first month documenting constraints, not tuning the objective function.
- Bad travel-time data. A purely Euclidean (straight-line) distance model produces unworkable plans in dense urban areas. Travel-time matrices need to come from an actual road network, ideally with historical or live traffic. This is also the most expensive part of the platform — third-party matrix APIs (HERE, Mapbox, PTV) cost real money at scale.
- Misaligned incentives. If the optimizer minimises distance but drivers are paid per stop, you'll see plans drivers fight. Align the objective function with the commercial reality of how the operation actually makes (and pays) money.
How to evaluate route optimization software
Five questions to put to any vendor on a demo call:
- Show me a plan against my data. Generic demos against the vendor's sample dataset prove nothing. A 50-stop instance from your last operational day, optimised on the demo call, separates engines that actually work in your domain from those that don't.
- What constraints can I express? Driver hours (561/2006 by jurisdiction), ADR compatibility, tail-lift requirements, customer-specific service durations, exclusive driver-customer assignments. If the answer is "we can do that in a custom build", walk.
- Where does your travel-time data come from? Generic Google Maps APIs are not built for HGV routing. PTV, HERE, and TomTom have HGV-specific networks. Make sure the engine uses one.
- How do you handle in-flight changes? Plan stability, driver-visible change frequency, and the ability to freeze actioned stops are the difference between dynamic routing as a feature and dynamic routing as a usable workflow.
- How is it priced? Per-stop, per-vehicle, per-call, flat monthly? Per-call pricing punishes high-frequency dynamic recompute; per-vehicle pricing punishes seasonal scaling. Map it against your operational pattern.
Transportial includes route optimization natively in the Plan Board, alongside multi-stop sequencing, EU 561/2006 driver-hours validation, ADR routing, and customer-facing tracking. It pairs with the OpenMove driver app for in-cab execution of the resulting plan and connects to PTV, HERE, and Mapbox for HGV-aware travel-time data. If you'd like to see it against your own operation, book a 30-minute demo.
For the broader context of how route optimization fits into a transport operation, see our guide to what a Transport Management System is and what it does.
Frequently asked questions
- What is route optimization in logistics?
- Route optimization is the process of computing the most efficient sequence of stops for a vehicle or fleet given time windows, vehicle constraints, road network conditions, and a cost objective — typically a weighted mix of distance, time, fuel, and emissions. In practice it produces driver-ready plans that minimise cost while respecting operational rules like driver hours, vehicle capacity, and customer service levels.
- How much can route optimization save?
- Realistic savings against a competently planned manual operation are 5–10% in distance, 10–15% additional stops per shift from cleaner allocation, 5–8% fuel reduction, and 20–30% planner-time reduction. Vendor headline numbers of 25–30% typically compare against unplanned or spreadsheet baselines and are not representative of a like-for-like upgrade.
- What is the difference between static and dynamic route optimization?
- Static routing computes plans once, typically the day before the operational day starts, and is appropriate for fleets with closed order books like grocery distribution. Dynamic routing recomputes continuously as new orders arrive, traffic shifts, or stops cancel, and is appropriate for last-mile, courier, and same-day networks. Dynamic engines must include plan-stability mechanisms (change cost in the objective function) to avoid disturbing driver plans every few minutes.
- What algorithms does route optimization use?
- Production route optimization uses metaheuristics — typically a construction heuristic (greedy insertion, savings algorithm) to build an initial feasible solution, followed by local-search improvement (2-opt, 3-opt, large neighbourhood search) and sometimes population-based methods (genetic algorithms). Exact methods like branch-and-cut are limited to small problem sizes because the search space is combinatorial: a 50-stop TSP has roughly 3 × 10⁶² possible sequences.
- What inputs does route optimization software need?
- Five inputs are required: stops (with geocoded addresses, service durations, and time windows), vehicles (with capacity, shift windows, and capability flags), drivers (with shift constraints and EU 561/2006 driver-hours state), network data (HGV-aware travel-time matrices and access restrictions), and an objective function (weights on distance, time, cost, CO₂, and SLA penalties).
- Can route optimization software handle multi-stop deliveries?
- Yes — multi-stop routing is the Vehicle Routing Problem with Time Windows (VRPTW), which is the core problem class commercial engines are built to solve. Production engines handle thousands of stops across heterogeneous fleets, with constraints for pickup-and-delivery pairs, multiple depots, electric-vehicle charge state, and customer-specific service levels.
- Should I optimize routes automatically or have a human approve them?
- Most production deployments use route optimization as a 'suggest plan' tool that a human planner reviews and approves. Full automation is technically possible but rarely deployed because the cost of a single wrong allocation (missed delivery to a key account) outweighs the marginal gain from removing the planner from the loop. Optimization adds the most value when it eliminates the rote sequencing work so the planner can focus on exceptions and customer relationships.
