Route Optimization for 200 Vans: Fuel Cost -18%

The Company

Kestrel Last Mile is a regional delivery carrier running 200 vans across a sprawling metro area, hauling parcels for national shippers, e-commerce brands and a roster of commercial accounts with regular delivery contracts. The company's economics are the unforgiving economics of last-mile logistics: thin margins per stop, high fixed costs in fleet and drivers, and a service promise that customers judge daily. Industry research widely cited by Capgemini estimates that last-mile delivery typically accounts for around 41% of total supply chain costs, which means the margin Kestrel keeps or loses is decided largely by how well each day's routes are planned and executed.

The operation ran on the experience of four veteran dispatchers. Between them they held decades of accumulated territory knowledge — which industrial park gate was locked after 10 a.m., which residential complex swallowed drivers for twenty minutes, which customer dock backed up at lunch. That knowledge was genuinely valuable and entirely undocumented. Around it sat a patchwork of tools: a mapping package for distances, printed manifests for drivers, and a whiteboard for the daily scramble. Kestrel was profitable, growing and — as leadership was beginning to understand — quietly fragile.

Where Things Stood

Route planning started every weekday between 4 and 6 a.m., when the four dispatchers built the day's routes by hand. Drivers regularly drew 130-plus stop days that could not physically fit inside their shift windows, so the overruns converted directly into overtime at the end of every long day and into failed deliveries that had to be retried the next one. The retry pattern was particularly expensive: a missed stop burned the fuel and driver time twice, disappointed the customer twice, and pushed the next day's plan further over capacity. Nobody had designed routes to fail; they simply exceeded what any human could optimize across 200 vans and a metro's worth of addresses.

The cost of this arithmetic was visible in the ledger. Fuel and overtime together ran $6.8M a year and climbed with every fuel-price move, a line item that rose whether or not volume did. On-time delivery sat at 92.1% — tolerable in the aggregate, but the failures were not evenly spread. They concentrated on the commercial accounts with tight delivery windows, and two of those customers had put the carrier on notice: windows were missed too often, and both were evaluating alternatives. On top of the financial exposure sat a personnel one. The dispatchers were the only people who understood the territorial quirks, and leadership knew the operation was one resignation away from losing knowledge that took years to rebuild and could not be hired at any price.

The Challenge

The challenge had three interlocking parts. The first was computational: 200 vans, thousands of daily stops, vehicle capacities, driver shift windows and customer time commitments form a problem that no human can optimize by intuition, however experienced — and the manual process was producing plans that failed on paper before a single van left the yard. The second was institutional: any solution that sidelined the dispatchers would be sabotaged quietly and rightly, because their judgment about sites and customers was real; any solution that depended on documenting their entire knowledge first would take a year and never ship. The third was commercial: the two at-risk accounts needed reliability they could put a number on, not reassurance.

There was also a hidden constraint that shaped the design. The carrier's day does not end when routes are printed — orders arrive mid-morning, traffic shifts by the hour, and some deliveries fail on first attempt. A planning tool that produced one beautiful route per morning would still leak savings every day after 9 a.m. Whatever Emerson Technology built had to replan as the day moved, keep dispatchers in charge of exceptions, and prove its own performance with data rather than asking the operations team to take the solver's word for it.

Discovery and Diagnosis

Emerson Technology opened with a three-week discovery embedded in the dispatch office, and the audit started with constraints rather than software. Working alongside the dispatchers, the team catalogued everything the morning process actually knew: van capacities and load limits, driver shift windows, commercial delivery windows, site-level quirks like dock hours and gate codes, and the informal rules — never route a new driver into the hillside neighborhoods, never promise the industrial park before 8 a.m. Each constraint was written down and structured, which was itself a first: much of it had lived only in the dispatchers' heads. The exercise deliberately treated the veterans as co-authors of the system rather than obstacles to it, a stance that paid for itself repeatedly through the rollout.

The data diagnosis quantified what the overruns already suggested. A sample of planned routes compared against GPS traces showed plans failing in predictable places: stop durations estimated too optimistically at commercial docks, routes built before the morning's order wave arrived, and no mechanism at all for adjusting once traffic or cancellations moved the underlying reality. Failed first attempts clustered on afternoon stops that the morning plan had already made mathematically unreachable. The audit also put numbers on the key-person risk: each dispatcher's territory knowledge was unique, non-overlapping and unrecorded, which meant the operation's planning capability had a bus factor of four — and really of one per territory.

The benchmark conversation framed the opportunity honestly. UPS has reported that its ORION route-optimization system saves the company roughly 100 million driving miles and hundreds of millions of dollars annually, so the category was proven at scale; Kestrel's question was how much of that pattern applied at 200 vans with commercial constraints. The answer, based on the waste visible in the GPS sample — unnecessary miles, overtime overruns, repeated delivery attempts — was that the gap was large enough to fund the project several times over.

The Solution

Emerson Technology built a route optimization service in Python around open-source OR-tools solvers, wrapped in an API that ingests orders, vehicle capacities, driver shift windows and live traffic feeds, and returns feasible, costed routes that the operation can actually execute. The architecture has three layers.

Digitizing the operating constraints

Every constraint surfaced in discovery became a first-class input: capacities, shift windows, commercial delivery windows, site quirks and driver-skill rules. Codifying them changed their status — a customer's delivery window became a constraint the solver respects, not a promise the phone makes. The constraint library lives in version control alongside the service, so a new customer contract, a fleet change or a new hire's restrictions are edited once and apply to every route the solver produces from that moment on. When a constraint is wrong, the fix is a data change rather than an argument at the whiteboard.

The solver and its replanning rhythm

The solver generates routes nightly against the full order book, then replans mid-morning as the day's reality arrives — new orders, failed first attempts returning to the pool, cancellations, and shifting traffic patterns. Dispatchers approve exceptions rather than build routes: the machine proposes, the veterans judge, and their local knowledge now lands on the 5% of decisions where it actually changes the outcome instead of being consumed by the 95% that is arithmetic. Replanning during the day captures the savings that static plans quietly leak by noon; a route built at 5 a.m. is a hypothesis, and the mid-morning replan is how the operation corrects it while there is still driving time left to correct it with.

The console, the driver view and the scorecard

A Next.js dispatch console shows each route with stop-level ETAs, exception flags and the day's running plan-versus-performance position, while drivers receive turn-by-turn sequencing through a mobile view. When the mid-morning replan moves a stop, drivers get live resequencing alerts with the reason attached — drivers follow plans they understand, and they quietly abandon plans that feel arbitrary. Van telemetry feeds a warehouse where every route's planned-versus-actual performance is scored daily in Power BI: miles driven versus miles planned, stop times estimated versus stop times real, windows promised versus windows met. The scorecard turns route quality from a one-time project into a measurement habit, and it flags drift — an optimistic stop-time assumption creeping in, a neighborhood going bad — before it becomes a missed window.

The First 90 Days

Weeks one and two were the constraint codification sprint, run with all four dispatchers in the room. The team structured vehicle profiles, shift windows, site quirks and the commercial windows for every contracted account, and agreed the ground rule that governed the whole engagement: the solver proposes, dispatchers approve and adjust, and every override is a data point. Nobody's knowledge was discarded; it was converted into inputs the machine could carry.

Weeks three through six ran the pilot at one depot with roughly 40 vans. Solver routes and dispatcher routes were built side by side each morning, and the depot ran a mixed fleet — some drivers on solver sequences, some on manual manifests — so the comparison would be honest rather than theoretical. The first week was humbling in the right direction: dispatchers overrode the solver on a set of hillside routes and were correct, which produced constraint fixes rather than resentment. By the third week the solver's plans were beating the manual ones on miles and shift fit, and the overtime overrun at the pilot depot was visibly shrinking week over week.

Weeks seven through ten took the service to the full 200-van fleet and delivered the pieces that made it livable: the Next.js console for dispatch, the driver mobile view with resequencing alerts, and the commercial delivery windows for the two at-risk accounts encoded as hard constraints the solver could not trade away. Those two accounts were visited personally and shown their windows entering the plan itself. Weeks eleven through thirteen hardened the operation: the Power BI planned-versus-actual scorecard went live, the mid-morning replan became a fixed daily ritual with named owners, and — as a deliberate test — a new dispatcher was onboarded using the system alone. The new hire reached productive routing in days rather than the months of apprenticeship the old territory knowledge demanded, which answered the key-person question more convincingly than any slide.

The Results

The first full year put numbers on the change. Fuel costs fell 18% — roughly $830K — while overtime dropped 26% as routes stopped overrunning shift windows. On-time delivery climbed from 92.1% to 97.4%, and completed stops per route rose 14% without adding a single vehicle, which meant the fleet absorbed growth that would previously have forced a purchase order. The two at-risk commercial accounts both renewed, citing reliable windows in writing. The US Department of Energy's fleet studies report that aggressive driving can lower fuel economy by up to 30%, but Kestrel's savings came from a simpler source: the vans stopped driving miles that should never have been in the plan at all.

The operational texture changed as much as the numbers. Dispatch mornings shifted from whiteboard construction to exception review, and the mid-morning replan caught order waves and traffic shifts that the old static plans absorbed as overtime and retries. Failed deliveries fell because routes stopped being unrealistic from the start, which in turn freed capacity the next day no longer spent on repeats. The dispatchers' role upgraded rather than eroded — they now manage exceptions, negotiate constraints and review the scorecard, and their knowledge lives in a constraint library the whole company can see. Planned-versus-actual scoring flags drift weekly, so the system's own quality is measured with the same discipline it brought to the fleet.

What Your Business Should Do

Kestrel's experience compresses into eight moves that any fleet operator can sequence. Digitize your constraints before optimizing anything: codify vehicle capacities, driver shift windows, customer delivery windows and site quirks first, because a solver without your real constraints will optimize the wrong problem beautifully. Blend solver output with dispatcher sense rather than replacing it — let the machine propose and your veterans approve and adjust, a division of labor that preserves hard-won judgment and ends the daily scramble that burns your best people. Replan during the day, not just nightly: orders arrive, traffic shifts and deliveries fail long after routes are printed, and mid-morning replanning captures the savings static plans quietly leak by noon. Give drivers resequencing, not just routes — push updated stop sequences to a mobile view with the reason attached, because drivers follow plans they understand and quietly abandon plans that feel arbitrary.

Then hold the system accountable to reality. Score planned versus actual daily by comparing planned routes with GPS traces, because route quality is a measurement habit rather than a one-time project. Treat commercial delivery windows as hard constraints the solver must respect, then sell that reliability at renewal — customers punish missed windows far harder than late residential drops. Keep territories from calcifying: manual territory knowledge becomes a single point of failure and quietly blocks optimization, so let the solver redraw boundaries as volume, fleet and staffing change. And tie the savings to the line items executives actually feel — fuel, overtime and redelivery costs — because route metrics mean very little to a board unless they show up in real spend.

Before you start, sit with the questions Kestrel's leadership had to answer: who really plans your routes today, and what happens to delivery if that person resigns; how many of your failed deliveries trace back to routes that were unrealistic from the start; what an 18% fuel saving would be worth across your fleet over a full year; which customers you have nearly lost over delivery windows you promised but could not guarantee; how quickly your dispatch can adjust when traffic, orders or cancellations shift mid-morning; and whether you know your planned-versus-actual gap per route, or only total miles driven. Work through the eight actions with your dispatch and operations leads, and return to those reflection questions each quarter to keep the capability honest.