A walkthrough on real NYC coordinates of the same last-mile routing methodology I run for enterprise logistics clients. Methodology is real. Numbers are real solver output for this scenario; in production deployments the absolute savings scale with the fleet size and stop density.
The Challenge
Look at any e-commerce or grocery delivery P&L and last-mile is the line that hurts. Long-haul trucking is mostly a solved cost problem — predictable lanes, full trailers, decent utilisation. Last-mile is the opposite: small parcels, variable demand, complicated stop sequences, and a driver paid by the hour. Even a single bad route compounds into late deliveries, overtime, missed promised time windows, and a customer-experience hit that nobody measures the same week.
The default operating pattern in most fleets is some version of "dispatch the next driver to the next-loaded truck and let them figure out the order." Drivers are smart and they optimise locally — but they don't optimise across multiple vehicles, they don't see tomorrow's stops, and they re-derive the routing from scratch every morning. The result is a fleet that's running 50–70% more kilometres than the math says it has to.
The Vehicle Routing Problem (VRP) — and its solvers — have existed since the 1950s. There is no good excuse not to be running one. The model I'm walking through here is the version I deploy with clients: Google's open-source OR-Tools, applied to 30 real NYC delivery stops with four available trucks and a cap on stops-per-truck for crew balance.
The Approach
1. Define the scenario. One depot in Midtown Manhattan + 30 delivery stops scattered across Manhattan, Brooklyn, Queens. Real NYC lat/long coordinates. Distance computed via Haversine (great-circle, which approximates well at city scale). Fleet of 4 trucks, max 12 stops per truck for crew balance.
2. The naive baseline. Single truck, visiting customer stops in random dispatch order — the order parcels arrived at the depot, not the order a planner would choose. This is the "next driver, next loaded truck" pattern, made explicit so the savings number means something.
3. Solve with OR-Tools. Construct a routing model with the Haversine distance matrix as the cost. Add a per-vehicle stops constraint so we balance load, not just minimise distance. Run with PATH_CHEAPEST_ARC as first solution + GUIDED_LOCAL_SEARCH as the metaheuristic, 5-second time limit. The solver finds a provably good (often optimal at this size) assignment in under a second.
4. Read the assignment as a fleet decision, not a math result. The output isn't just "98.6 km." It's three trucks active, one parked, total fleet hours roughly halved, depot dwell time on the leftover driver freed up for the next shift. That's a labour-budget conversation, not a routing puzzle.
The Outcome
The solver returned 98.6 km total across three active trucks, against a naive baseline of 239.3 km — a 58.8% reduction in distance driven. The fourth truck wasn't needed (excess capacity surfaces immediately when the assignment is solved, not after a quarter of complaints). Stops distributed 7 / 11 / 12 across the active fleet.
On a real fleet, the 59% distance number is the headline, but the secondary effects matter more:
- Driver hours fall by roughly the same percentage — a labour cost that's typically 40–60% of last-mile spend.
- Promised delivery windows get tighter and more reliable because the routes are geographically continuous (one borough at a time), not zigzag.
- The "do we need to lease the 4th truck?" question goes from a feel to a number. In this scenario, the answer is no, not for this stop density.
The bigger pattern this analysis crystallises: the existence of a 1950s algorithm is not a reason it's being used. Most operating fleets are leaving 50–70% mileage on the floor not because the math is hard, but because the workflow to plug current stop-data into the math has never been built.
Business Impact
In production, this analysis becomes a daily batch job — stops upload at 5am, routes drop into the driver app by 6am, the dispatch team approves exceptions, trucks roll. The model earns its keep when the dispatch team starts pushing back on operations teams who try to add stops to a route the solver already declined — that's the moment the math has become organisational.
Key Takeaways
- Realistic baselines matter. Geographically pre-sorted "naive" is a fake baseline. Use random dispatch order — that's what real depots actually look like at 5am.
- Constrain for balance, not just total distance. If you only minimise distance, one truck gets 28 stops and one gets 2. The labour-cost conversation immediately disappears.
- OR-Tools is free and proven. There's no reason to start with anything else for VRP — graduate to CPLEX/Gurobi only if the problem outgrows it.
- The 4th truck question is now a number. The hardest political conversation in last-mile (fleet sizing) becomes an output of the solver, not a gut feel.