Delivery Route Optimization: Why the Best Route on Paper Falls Apart by 7am

Delivery route optimization is the process of assigning and sequencing stops across a fleet so every route respects real-world constraints: time windows, vehicle capacity, service time at each stop, driver shifts and site access rules, while minimising total distance, driving time and cost. It solves the vehicle routing problem. Consumer mapping apps do not.

That distinction is not academic. It is the difference between a plan that survives contact with the morning and one that starts failing before most offices open.

The 7am Problem: A Route That Was Mathematically Perfect and Operationally Useless

Picture a dispatcher building tomorrow's morning run on shortest-distance logic.

Three drops matter. A bakery order that has to be inside the shop before the doors open at 7:00. A chilled leg that cannot sit in the back of a van past a temperature threshold. A pharmacy delivery that needs a signature from a named recipient during their reception hours.

The map says the sequence is optimal. Fewest kilometres, tidiest loop, no backtracking.

By 9am, three stops have failed.

The bakery drop arrived at 8:15 because it sat third in the loop instead of first. The chilled pallets were loaded at the back of the van and came off last. The pharmacy signature was unavailable because the driver hit the site during a staff changeover.

None of that is a mapping failure. The distance calculation was correct. The plan was wrong because the planner was solving the wrong problem.

Shortest distance is one objective among many. Real delivery routes carry hard limits the map has never been told about, and when the solver does not know those limits exist, it optimises straight through them.

This is the gap most route planning advice leaves open. Plenty of guides tell you to account for service time or parking access. Very few define the full constraint set, show you how to prove the change worked, or give you a way to test a solver before you sign anything.

That is what the rest of this piece does.

What Delivery Route Optimization Actually Is (and Why Google Maps Can't Do It)

Formally, delivery route optimization is a version of the vehicle routing problem: given a set of orders, a set of vehicles and a set of rules, find the assignment and sequence that costs the least without breaking any rule.

The awkward part is the maths. The number of possible route combinations grows factorially with stop count, so once you are past roughly 25 to 30 stops per vehicle, no planner reliably finds a good answer by hand. They find a defensible answer. That is a different thing.

Now the mapping app question, because it comes up in every evaluation.

Google Maps, Waze and Apple Maps sequence one vehicle's stops and cap the waypoint count. They are excellent at that job.

What they cannot do is split tomorrow's order book across six drivers. They do not know your van holds 12 pallets. They cannot enforce a customer's 9:00 to 11:00 window, cannot add 12 minutes of unloading time at a site with a single loading bay, and cannot stop a route running 90 minutes past a driver's shift.

Those are the constraints that decide whether deliveries land. A mapping app optimises the drive. Route optimisation software optimises the day.

There is a commercial reason this matters more every year. According to McKinsey's last-mile delivery research, the final leg accounts for roughly half of total parcel delivery cost, which makes route-level decisions the single largest cost lever most operators have. Read the McKinsey analysis on how customer demands are reshaping last-mile delivery for the full breakdown.

The 11 Constraints Your Solver Has to Model, and What Breaks When It Doesn't

This table is the core of the article. Print it, take it into your next vendor call, and ask which rows the product handles natively rather than through a workaround.

Constraint	Why naive routing gets it wrong	What breaks operationally
Delivery time windows	Distance logic treats every stop as available all day	Refused deliveries, redelivery cost, SLA breaches
Vehicle capacity (weight, volume, pallets)	Stop count is used as a proxy for load	Driver returns to depot mid-run to reload
Service time at each stop	Only drive time is counted, dwell time is assumed zero	ETAs drift by mid-morning and never recover
Driver shifts and working hours	Route length is unbounded by shift length	Unplanned overtime, fatigue and compliance exposure
Breaks and rest periods	Breaks are left out of the timeline entirely	Afternoon stops run late even when the morning was clean
Multi-depot and depot return	One start point is assumed for the whole fleet	Drivers cross-cross territory other drivers already cover
Site access rules (dock, crane, floor level, parking)	Address is treated as a point, not a place with rules	Driver arrives with the wrong vehicle or no way to unload
Vehicle-type restrictions	All vehicles are interchangeable in the model	A chilled order lands on a non-refrigerated van
Pickup and delivery pairing	Collection and drop are treated as unrelated stops	Drop is sequenced before the item has been collected
Recurring and fixed stops	Every day is planned from scratch with no memory	Regular customers lose their familiar driver and slot
Traffic patterns and road restrictions	Static travel times ignore time of day and truck bans	Plans look fine at 5am and unravel in peak hour

Two things to notice about that list.

First, only the last row is about roads. Everything above it is about your business, your customers and your people.

Second, constraints interact. Add a time window and a capacity limit and a shift cap to the same route and the feasible solution space collapses fast. That is exactly why a human planner and a spreadsheet stop being good enough at scale.

The KPIs That Prove It Worked: Baselines, Targets, and Where the Data Comes From

Most optimisation projects fail the review meeting, not the go-live. Someone asks "so did it work?" and nobody can answer with a number.

Fix that before you change anything. Record a baseline for two full weeks, using the same weekday mix you will compare against later.

Metric	How to baseline it	What good movement looks like	Where the data comes from
Total kilometres per route	Odometer or GPS trace, averaged per route per day	Down, at equal or higher stop count	Vehicle tracking or driver app trace
Stops per vehicle per day	Completed stops divided by vehicles on road	Up, without shift creep	Completed-stop records
Driving time vs service time	Split the working day into the two buckets	Driving share falls, service share holds	Arrival and departure timestamps
On-time / SLA rate	Stops delivered inside the promised window	Up, and stable across the worst day of the fortnight	Proof-of-delivery timestamps
Failed deliveries and redeliveries	Count by exception reason, not just total	Down, especially window-related failures	Driver app exception codes
Planning time	Stopwatch the dispatcher for a week, honestly	Manual hours become automated minutes	Dispatcher time log
Cost per drop	Labour plus fuel plus vehicle cost, divided by stops	Down at constant service level	Payroll, fuel cards, route records

Here is the part teams skip: none of those numbers exist unless the field is feeding them back.

If drivers confirm deliveries by phone call or text, you have no timestamps, no exception reasons and no way to tell a late delivery from a late data entry. Photo, signature and geo-stamped proof of delivery is not just a customer-dispute tool. It is the measurement layer for the whole exercise.

Cost per drop deserves one caveat. Fuel is volatile, so track kilometres alongside dollars. The International Energy Agency's work on road freight fuel use makes the same point from the emissions side: total distance driven is the lever you actually control.

Five Verticals Where the Constraints Change the Answer Entirely

The same solver, pointed at five different operations, should produce five very different-looking plans. Here is why.

Cold chain. Temperature-sensitive freight adds a hard ceiling on how long product can sit in the van, which pushes sequencing decisions that shortest-distance logic would never make. The chilled leg goes first even when it costs extra kilometres. Refrigerated courier work also leans hard on delivery evidence, which is the routing problem Perth Couriers operates in.

Early-morning fresh goods. Bakery and fresh produce runs are defined by a window that closes, not one that opens. Deliver at 6:40 and it works. Deliver at 7:10 and the shop has already served customers without the stock. That is the class of problem Husk Bakery routes around.

Pharmacy and compliance-sensitive delivery. Chain of custody turns a delivery into an evidence event: correct recipient, correct handover, correct record. Routing has to allow enough service time for that handover instead of assuming a doorstep drop, which shapes how prescription delivery operations like SuperPharmacy plan a day.

Heavy goods and site access. Building materials routing is a capacity and vehicle-type problem first. Crane access, site entry hours and which truck can physically reach the drop point all rule out sequences that look fine on a map, as any building supplies delivery operation will recognise.

Scheduled collections and reverse logistics. Pickups run the capacity constraint backwards. The vehicle fills as the route progresses, so the last stops are the ones at risk, and recurring visit frequency matters more than customer windows. Container collection work such as Containers for Change sits squarely in this shape.

Different objective functions, same underlying problem. If a platform only handles one of these shapes well, you will find out in month three.

How to Test Route Optimization Software on Your Own Data (5-Step Playbook)

Vendor demos use clean data. Your operation does not have clean data. So test with yours.

1. Export two weeks of real orders, including your busiest day and your worst day. The worst day is the one that matters. Any solver looks good on a Tuesday.
2. Document your actual constraint set using the 11-row table above. Write down the ones you currently handle by memory, because those are the ones that break a rollout.
3. Run the identical dataset through every shortlisted tool. Same orders, same vehicles, same rules. If a vendor cannot accept your file, that is a finding in itself.
4. Compare three outputs, in this order: constraint violations first, then stops per driver, then total kilometres. A plan that saves distance by quietly breaking a time window is not a better plan.
5. Pilot one depot or one route group for four weeks before you roll out. Measure against the baseline you recorded, not against how the old routes felt.

One more filter. Ask each vendor to show you the plan for the day they would rather you skipped. The answer tells you more than the feature list.

Route Planner vs Delivery Platform vs Enterprise Engine: Which Category You Actually Need

Four categories show up in most shortlists, and they are not interchangeable.

Category	Constraint handling	Driver app and POD	Recurring routes	Exportable metrics	Best for
Consumer maps app	None beyond stop order	None	None	None	One driver, a handful of stops, no promises made
Standalone route planner	Partial: windows and basic capacity	Partial or add-on	Limited	Basic route summaries	Teams that only need a better stop sequence
Delivery management platform (Locate2u)	Full: windows, capacity, service time, shifts, vehicle type, multi-depot, pickups	Native: photo, signature, geo-stamped, exception codes	Native recurring and fixed stops	Full KPI export plus open API	Micro-fleets through to 1000+ driver operations on one platform
Enterprise routing engine	Strong, usually configuration-heavy	Varies, often a separate module	Strong	Strong, with implementation effort	Network design projects with a dedicated internal team

Enterprise engines do serious modelling work and standalone planners are genuinely quick to adopt. The catch with both is that the constraint model, the driver app, the customer ETA and the delivery evidence end up in different systems, which is where your KPI data quietly disappears.

Volume pressure is not easing either. Statista put global parcel volume at roughly 161 billion parcels in 2022, with stop density and window expectations climbing alongside it. Picking a category you will outgrow in 18 months is an expensive way to save three months of evaluation.

Where Locate2u Fits

Locate2u sits in the delivery management platform column, deliberately.

The route optimisation engine models the full constraint set, the driver app captures proof of delivery and exception reasons in the same system, customers get live ETAs, and the resulting metrics export without a data project.

It runs the same way for a three-van operation and a 1000-driver fleet, which means you are not re-platforming the year you grow. Pricing starts from US$25 per user per month and is published openly on the Locate2u pricing page.

If you are still shortlisting, our breakdown of how route optimization software is evaluated pairs well with the five-step test above.

Delivery Route Optimization FAQs

What is delivery route optimization?

It is the process of assigning stops to vehicles and sequencing them so each route satisfies operational constraints such as time windows, vehicle capacity, service time, driver shifts and site access, while minimising distance, driving time and cost. It is a fleet-level assignment problem, not a single-vehicle mapping exercise.

Why can't I just use Google Maps for delivery routes?

Google Maps optimises one vehicle's stop order and caps waypoints. It cannot split a day's orders across multiple drivers, enforce a 9:00 to 11:00 customer window, respect a van's pallet capacity, account for unloading time, or stop a route running past a driver's shift.

What is the difference between route planning and route optimization?

Route planning is deciding which stops go on which route, often manually or by geographic zone. Route optimization uses an algorithm to evaluate the combinations against defined constraints and objectives, producing an assignment no planner can reliably reach by hand past roughly 25 to 30 stops per vehicle.

How do I measure whether route optimization worked?

Record a baseline for two weeks before changing anything, then compare the same seven metrics afterwards: kilometres per route, stops per vehicle per day, driving versus service time, on-time rate, failed deliveries, planning time and cost per drop. Proof-of-delivery timestamps and exception codes make those measurable.

How should I test route optimization software before buying?

Export two weeks of real orders including your busiest and worst day, document your actual constraint set, then run that identical dataset through every shortlisted tool. Compare constraint violations first, then stops per driver and total kilometres. A demo built on clean sample data proves nothing about your operation.

Does route optimization work for pickups and collections, not just deliveries?

Yes. Scheduled collections and reverse logistics are modelled as the same vehicle routing problem, with capacity filling across the route instead of emptying. The constraints that matter shift toward container volume, site access windows and recurring visit frequency rather than customer delivery windows.

Start with the constraint table. If your current system cannot enforce even half of those rows, the routes your team is running are being held together by dispatcher memory, and that is not a system you can scale. Book a walkthrough of Locate2u's route optimisation with your own two weeks of orders and see what the plan looks like when every rule is in the model.