Can Predictive Routing Cut Last-Mile Delivery Failures?

A regional logistics provider used ML-based predictive routing and delivery-window optimisation to target a 25–35% reduction in failed first-attempt deliveries — saving an estimated £3–5 per parcel on re-delivery costs.

Key Takeaway

A regional logistics provider used ML-based predictive routing and delivery-window optimisation to target a 25–35% reduction in failed first-attempt deliveries — saving an estimated £3–5 per parcel on re-delivery costs.

The Business Challenge

Picture a UK-based logistics company handling around 80,000 parcels per day across urban and semi-rural routes. Their routing engine was rules-based: sort by postcode, assign to the nearest depot, sequence stops by shortest distance. It worked — until it didn't.

Failed first-attempt deliveries ran at 12–15% across the network. Each failure triggered a re-delivery attempt, a customer service call, or a return to depot. At an estimated cost of £4–6 per failed delivery, the company was haemorrhaging margins on a problem that traditional routing could not solve. The issue was not route distance. It was route timing — drivers arriving when nobody was home.

Why Now: Predictive Routing Last-Mile Delivery Is Reaching Production Maturity

Three developments have made ML-based predictive routing last-mile delivery a viable investment for mid-sized operators, not just the major carriers.

First, delivery behaviour data has become richer. Smart doorbells, delivery photo confirmation, and real-time GPS tracking generate granular signals about when and where deliveries succeed or fail. This data, combined with historical delivery outcomes, gives models enough signal to predict failure risk at the individual stop level.

Second, cloud-based optimisation solvers — both open-source and commercial — can now handle dynamic re-sequencing of routes in near-real-time, making it practical to adjust routes based on model predictions rather than relying solely on static planning.

Third, customer expectations have shifted. Same-day and next-day delivery windows are now standard. Customers tolerate fewer failed attempts and are more likely to switch providers after a poor delivery experience. Reducing failures is not just a cost play — it is a retention play.

The Approach

The logistics provider's engineering team, working with an external product engineering partner, built the system in three phases.

Phase 1: Delivery Outcome Modelling (Weeks 1–5)

The team assembled 18 months of delivery outcome data: successful vs. failed attempts, timestamped to the minute, with associated features — delivery address type (house, flat, commercial), time of day, day of week, weather conditions, and historical success rate at that address.

They trained a gradient-boosted binary classification model predicting the probability of delivery failure for each stop at each potential time slot. The model achieved an AUC of 0.81 on held-out test data — strong enough to meaningfully influence routing decisions.

The most predictive features were: historical delivery success rate at the specific address (by far the strongest signal), time-of-day band, and whether the address was a flat with no safe place for parcels.

Phase 2: Route Optimisation Integration (Weeks 4–8)

The failure-probability score was injected as a constraint into the route optimisation engine. The solver now balanced three objectives: minimise total route distance, maximise delivery success probability, and respect driver shift-time limits.

In practice, this meant the system would schedule high-risk residential addresses for evening slots (when residents were more likely to be home) and cluster low-risk commercial deliveries in morning runs. The trade-off was a modest increase in total route distance (5–8%) in exchange for significantly higher first-attempt success rates.

The engineering challenge was latency. The optimisation solver needed to produce routes for 80,000 parcels within a 45-minute planning window each morning. The team achieved this by parallelising the solver across depot-level partitions and pre-computing failure scores in a nightly batch job.

Phase 3: Dynamic Re-Routing and Customer Communication (Weeks 7–12)

For same-day adjustments, the team built a lightweight re-routing service that triggered when real-time signals changed — a traffic incident blocking a route, a customer updating their availability via SMS, or a driver running ahead of schedule. This service re-sequenced remaining stops using the same optimisation logic, pushing updated ETAs to customers.

The customer communication layer was critical. Automated SMS notifications with a 30-minute delivery window and a one-tap reschedule link gave recipients agency, reducing no-one-home failures by a further margin.

Illustrative Outcomes

This is an illustrative scenario, but a transformation like this typically targets:

• First-attempt delivery success rate improvement from 85–88% to 93–96%, driven by time-of-day optimisation and address-level risk scoring.
• Re-delivery cost savings of 25–35% as fewer parcels cycle through second and third attempts.
• Customer complaint reduction of 15–20% related to missed deliveries.
• Driver utilisation improvement of 8–12% as fewer wasted stops free up capacity for additional deliveries.
• Modest route distance increase of 5–8%, a deliberate trade-off against the larger savings from reduced failures.

These ranges reflect what the logistics industry reports for comparable ML-based routing deployments.

What Good Looks Like: A Checklist

• Historical delivery outcome data is the foundation. Without at least 12 months of timestamped success/failure records, the model lacks signal.
• Address-level features matter most. Aggregate postcode-level models underperform. Invest in address-level feature engineering.
• Trade-off transparency is essential. Stakeholders must understand and accept that total route distance may increase slightly to achieve higher success rates.
• Customer communication closes the loop. The best routing model in the world cannot help if the recipient has no way to signal their availability.
• Start with one depot or region. Prove the economics before rolling out network-wide.
• Monitor for drift. Customer behaviour changes — work-from-home patterns, new builds, seasonal shifts. Retrain quarterly at minimum.

Where Skillikz Fits

Skillikz brings product engineering depth to logistics optimisation — building the ML models, the solver integration, and the real-time APIs that connect predictions to driver apps and customer notifications. Our teams have delivered production systems that handle the messy realities of logistics data: inconsistent address formats, GPS drift, and legacy depot systems. If your last-mile delivery failure rates are eating into margins, we can help design and build a predictive routing system that actually ships.

Frequently Asked Questions

What data is needed to build a predictive routing model?

At minimum: 12–18 months of delivery attempt records with timestamps, outcomes (success/fail/partial), and address-level detail. GPS traces, customer communication logs, and weather data improve accuracy but can be added later.

How does predictive routing differ from standard route optimisation?

Standard route optimisation minimises distance or time. Predictive routing adds a delivery success probability constraint, so the solver considers when a delivery is likely to succeed, not just how to get there fastest.

Does this require replacing our existing routing system?

Not necessarily. Most implementations inject failure-probability scores as an additional constraint into the existing solver. The ML model sits alongside your routing engine, not in place of it.

What is the typical payback period?

For a mid-sized logistics operator (50,000–100,000 parcels per day), the reduction in re-delivery costs typically pays back the development investment within 6–10 months.

Can this work for B2B deliveries as well as B2C?

Yes, though the model features differ. B2B deliveries fail for different reasons — loading dock availability, reception hours, purchase order mismatches. The approach is the same; the feature engineering adapts.