Route optimization as a concept is not new. The Vehicle Routing Problem has been studied for 65 years. Good open-source and commercial solvers exist. The problem of finding near-optimal delivery routes given a set of stops, time windows, vehicle capacities, and driver constraints is well-understood algorithmically. Any new last-mile software that pitches "better route optimization" as its primary differentiation is selling a commodity in a wrapper.
The real last-mile intelligence challenge is different. It's about what happens after the route is planned — the continuous replanning problem, the driver behavior model, the customer availability prediction, and the exception handling logic that together determine whether a 200-stop delivery route completes at 94% first-attempt success or 73% first-attempt success. That 21-point spread is worth several euros per stop in redelivery cost. At scale, it's the difference between a profitable last-mile operation and one that loses money on volume.
The replanning problem
A route planned at 06:30 for a driver leaving at 07:00 is based on assumptions about traffic, stop access, customer availability, and vehicle condition that are already partially outdated by departure. By 09:00, three things have changed: the traffic model has updated based on real-time conditions, two customers have called to request a delivery time change, and the driver has fallen 12 minutes behind because of an unexpectedly difficult access situation at stop 4.
Static route optimization deals with this by ignoring it — the driver gets the original route and deviates manually when necessary, or the dispatcher intervenes when a customer complaint arrives. This is how the majority of mid-sized last-mile operators still run their fleets. The gap in efficiency is large and chronic.
Dynamic replanning changes the operating model: the route is continuously recalculated in response to real-time conditions, and driver instructions are updated in near-real-time via a driver app. The computational challenge is that you can't rerun a full VRP solver every five minutes across a fleet of 80 vehicles — the solve time is too long and the frequent instruction changes destabilize driver behavior. The algorithmic approach that actually works is a combination of an initial full-solve plus a fast local search that makes targeted insertions and swaps in response to specific exceptions without reoptimizing the whole route structure. Getting this right requires both algorithmic sophistication and deep integration with the real-time inputs that drive replanning decisions.
Customer availability as a prediction problem
The first-attempt delivery success rate is the metric that determines the economics of last-mile. Redelivery costs are high — a failed delivery attempt typically costs 60–80% of the first delivery attempt cost, depending on the network. The failure causes customer dissatisfaction. And the operational disruption to the route cascades: a failed stop at position 14 changes the arrival time estimate for stops 15–25, which may trigger additional failures if those customers have narrow availability windows.
Most last-mile operators deal with availability uncertainty by giving customers wide delivery windows — "we'll be there between 2pm and 6pm" — and accepting the resulting customer experience degradation as a cost of operation. The better solution is to predict customer availability at the stop level and route accordingly. A model trained on historical delivery data for a given postcode, customer, and time-of-day combination can predict the probability that a customer is home with meaningful accuracy. Routing to high-availability-probability stops in sequence, and clustering low-confidence stops into windows where the driver can attempt and retry within the same route block, changes the first-attempt success rate significantly.
This is not theoretical. The data exists: every last-mile operator with a driver app has delivery attempt outcome data at the stop level, timestamped, with customer notification response data. The operators who have built predictive availability models from this data report first-attempt success improvements in the 8–15 percentage point range. The ones who haven't are leaving that improvement on the table.
Driver behavior as a system component
The most underappreciated variable in last-mile optimization is driver behavior. Drivers are not interchangeable execution units. They have local knowledge — the back entrance that's faster than the front, the apartment building where the intercom doesn't work so you have to call, the industrial estate where parking is impossible between 11:30 and 13:00. This knowledge is valuable and it's not captured in any data system.
Smart last-mile software treats driver behavior as a signal, not a deviation. When drivers consistently re-sequence stops in a certain postcode away from the algorithm's suggestion, there's usually a reason. Learning from those re-sequences — identifying which algorithmic suggestions drivers override and why — improves the model. A driver that systematically moves a specific office building to the afternoon is telling you something about access conditions at that address that your address database doesn't contain.
Building a driver-behavior learning loop requires driver app adoption (which is its own organizational challenge) and ML infrastructure that can distinguish deliberate local-knowledge overrides from arbitrary deviation. But the operators who build this capability end up with a last-mile model that improves with use — a genuine data flywheel rather than a static optimization tool.
What we look for in last-mile AI
We invested in FourKites in 2024 because the founding team understood that supply chain visibility is the precondition for last-mile optimization — you cannot optimize what you cannot see in real time. Their platform provides predictive ETAs and dynamic exception management across the full shipment lifecycle, and the data they generate feeds directly into the route-level decisions that last-mile operators need to make.
We are not saying that the static route planning problem is trivial — there is genuine engineering complexity in building a fast, accurate solver for large instances across complex constraint sets. What we are saying is that static planning is a commodity capability, and any company pitching last-mile intelligence needs to have a clear answer to the replanning problem, the availability prediction problem, and the driver behavior learning problem. Those three together define whether a last-mile intelligence platform creates durable operational value or just automates a planning workflow that wasn't the bottleneck.
The unit economics framing
For operators evaluating last-mile intelligence software, the relevant benchmark is cost-per-attempted-delivery versus first-attempt-success-rate. A 5-point improvement in first-attempt success on a route with a 2.00 EUR per-stop redelivery cost, running 500 stops per day, saves 50 EUR per day before software cost. At 250 operating days per year, that's 12,500 EUR per vehicle per year in avoided redelivery cost. For a fleet of 20 vehicles, the business case for 50,000–100,000 EUR annual software investment is straightforward. The question is whether the software actually moves the metric, and the answer depends entirely on whether it's solving the real problem or just wrapping route planning.