Last Mile Delivery Metrics: Why Most Teams Only Find Out They Failed Too Late
Drafted with AI assistance, edited and fact-checked by Sean Flannery. See our editorial policy.
Last mile delivery metrics are the KPIs that measure the final delivery leg: on-time delivery rate, first-attempt success rate, cost per delivery, order accuracy, and average service time per stop. The most useful ones are leading indicators like planned-vs-actual route drift that warn you before a window is missed, not lagging ones you read after the customer complains.
The metric that caught a failed run before the driver left the depot
Picture a mid-morning at a busy courier fleet. Twelve drivers are out, the day was planned tight, and everything looks fine on the board. Then the afternoon WISMO calls start landing, one after another, each one a customer asking where their order is. By the time the dispatcher realises three routes ran long, the windows are already blown. The metric that told them they failed, on-time delivery rate, only updated after the failure was locked in.
This is the trap most last-mile teams sit in. They measure results after the customer has already been let down. The fleets that get ahead of it, like refrigerated-goods and dairy operators such as Perth Couriers, watch a different kind of number: planned-vs-actual route duration drift. When a run starts slipping behind its planned schedule mid-morning, that drift shows up while the day can still be re-sequenced, drivers rebalanced, and at-risk customers notified before their window closes. Same delivery, completely different outcome, because the metric fired early instead of late.
That gap between a metric that warns you and a metric that reports on you is the entire point of this guide. Most articles hand you a list of KPIs and a formula. This one tells you which metrics fire early, which fire too late, and exactly what to do when each one turns bad.
Leading vs lagging: why your dashboard is telling you yesterday's news
Every last-mile metric falls into one of two camps, and confusing them is why so many dashboards feel busy but useless.
Lagging indicators report on what already happened. Claims rate, return rate, customer satisfaction, on-time delivery rate at end of day. They are essential for scoring performance and spotting trends, but by the time they move, the customer has already had the experience. You cannot fix a delivery that lagging metrics report on, because it is finished.
Leading indicators predict or flag problems while you can still act. Planned-vs-actual route drift, predicted delivery success, exception alerts, route adherence. These fire during the run. A driver falling 40 minutes behind plan by 10am is a leading signal you can respond to at 10:05, not something you discover in tomorrow's report.
The single most valuable move a fleet can make is shifting its attention left, from lagging scorekeeping toward leading prevention. You still track the lagging metrics; you just stop relying on them as your early-warning system, because they were never built for that job. Throughout the metric breakdown below, each KPI is tagged so you know which are for prevention and which are for review.
The essential last mile delivery metrics (definition, formula, benchmark, data source, and the lever to pull)
Here is the fast reference. Every metric below carries a definition, a formula, a benchmark framed as a common starting point (never a universal law), the data source that feeds it, the lever you pull when it goes bad, and whether it fires early (leading) or late (lagging).
| Metric | Type | Formula | Common starting target | Data source | Lever to pull when it's bad |
|---|---|---|---|---|---|
| On-time delivery rate | Lagging | (On-time deliveries / total) x 100 | 95%+ e-commerce, 98%+ pharma | POD timestamps vs booked window | Re-optimise routes, tighten window promises |
| First-attempt success rate | Lagging | (Successful first attempts / total) x 100 | 90%+, mature ops 95%+ | Driver app status, POD | Improve address data, add ETA notifications |
| Cost per delivery | Lagging | Total delivery cost / deliveries completed | Set against your margin, not a fixed figure | Route plans, payroll, fuel, vehicle costs | Increase stop density, cut redelivery |
| Cost per km/mile | Lagging | Total route cost / distance driven | Benchmark against your own fleet history | GPS distance, cost inputs | Re-sequence stops, reduce empty running |
| Order accuracy rate | Lagging | (Correct orders / total) x 100 | 99%+ where accuracy is critical | Scan events, POD, returns log | Barcode scan at load, tighten pick process |
| Average service time per stop | Leading | Total on-site time / stops completed | 2-4 min residential, 5-8 min commercial | Driver app dwell timestamps | Adjust route timing, review access issues |
| Route adherence | Leading | (Stops in planned sequence / total) x 100 | High, with room for live re-routing | GPS vs planned route | Retrain, investigate why drivers deviate |
| Planned-vs-actual route drift | Leading | Actual route duration − planned duration | Flag any sustained positive drift live | Live GPS vs plan | Rebalance loads mid-shift, notify at-risk stops |
| Failed delivery rate | Lagging | (Failed deliveries / total) x 100 | As low as your model allows | Driver app exception codes | Fix root cause codes, add pre-delivery comms |
| Claims / damage rate | Lagging | (Claims / total deliveries) x 100 | Under 1% for most parcel ops | Claims log, POD photos | Improve handling, capture condition at POD |
| Return rate | Lagging | (Returned deliveries / total) x 100 | Varies sharply by category | Returns system, order data | Fix accuracy and damage upstream |
| Tracking / visibility completeness | Leading | (Deliveries with live tracking / total) x 100 | Aim for 100% of active jobs | Driver app, GPS coverage | Close app-usage gaps, fix dead zones |
| Driver utilisation | Leading | (Productive driving + service time / shift) x 100 | High without breaching fatigue limits | GPS, driver app, roster | Rebalance routes, reduce idle and wait time |
| Average delivery time | Lagging | Total time depot-to-door / deliveries | Trend against your own baseline | Dispatch and POD timestamps | Optimise sequencing, cut depot dwell |
| WISMO / contact rate | Lagging | (WISMO contacts / deliveries) x 100 | Falls as proactive comms improve | Support tickets, call logs | Send proactive ETA and delay notifications |
On-time delivery rate (lagging)
The headline number for most fleets. On-time delivery rate = (deliveries completed within the promised window / total deliveries) x 100 over a set period. A common starting target is 95% or higher for e-commerce, and pharma and healthcare often push toward 98%. The result depends entirely on how you define "on time", so lock that rule first. When it drops, the lever is route re-optimisation and honest window promises; a rate that keeps missing usually means you are promising windows your routes cannot physically hit. Our route optimisation tightens sequencing so promised windows are realistic before drivers roll.
First-attempt delivery success rate (lagging)
First-attempt success = (successful first deliveries / total deliveries) x 100. This one drives cost harder than almost any other metric, because every failed first attempt triggers a redelivery that compounds cost per delivery. Around 90% is a reasonable starting target; mature operations clear 95%. Bad data and poor timing are the usual culprits. The levers are better address validation, tighter windows, and proactive ETA notifications so the customer is home. Strong proof of delivery capture also confirms exactly what happened on a failed attempt so you can fix the pattern.
Cost per delivery and cost per km (lagging)
Cost per delivery = total delivery cost / deliveries completed. Cost per km = total route cost / distance driven. These matter because last-mile delivery can represent up to half of total shipping cost, per McKinsey analysis, so small movements here move the whole P&L. There is no universal target; benchmark against your own fleet history and margin. The levers are increasing stop density, cutting empty running, and eliminating the redelivery costs that failed attempts pile on.
Order accuracy rate (lagging)
Order accuracy = (correct orders delivered / total) x 100. Where accuracy carries compliance or safety weight, such as prescription delivery handled by operators like SuperPharmacy, this metric sits alongside chain-of-custody visibility as a core measure. The levers are scanning at load, tightening the pick process, and capturing clear POD so disputes are settled with evidence, not memory.
Service time per stop and route adherence (leading)
These two fire early. Service time per stop = total on-site time / stops completed; a common range is 2-4 minutes residential and 5-8 minutes commercial. Route adherence = (stops completed in planned sequence / total) x 100. When drivers drift off sequence or dwell too long, your planned day quietly falls apart before the on-time number even registers it. Watch these live to catch a slipping run while it is still fixable.
Failed delivery, claims, and return rate (lagging)
Failed delivery rate, claims/damage rate, and return rate are your quality tail. Claims under 1% is a reasonable bar for most parcel operations, though heavy goods and site deliveries carry different handling risk. Photo-based POD at the point of handover is the single best defence against damage disputes, because condition is recorded the moment the item changes hands.
Visibility, utilisation, delivery time, and WISMO (mixed)
Tracking completeness (aim for 100% of active jobs on live tracking) and driver utilisation are leading; average delivery time and WISMO contact rate are lagging. WISMO is the honest one: a high "where is my order" contact rate almost always means your real-time tracking and proactive notifications are not reaching customers. Gartner names visibility and exception management as top priorities precisely because they cut WISMO and lift on-time performance at the same time.
Planning metrics vs execution metrics: what to watch before and during the run
There is a second lens that sits on top of leading and lagging: when in the day you can act on a metric.
- Planning metrics tell you if the day is set up to succeed before a driver leaves: stops per route, planned route duration, planned distance, and load balance across drivers. If the plan is unrealistic, no amount of good driving saves it.
- Execution metrics tell you how the run is actually going in real time: planned-vs-actual drift, route adherence, service time per stop, and live exception alerts. These are where you intervene mid-shift.
The Perth courier scenario at the top works because a planning problem (windows promised too tightly) got caught by an execution metric (drift) early enough to fix. Watch both ends and the failures stop reaching the customer.
Advanced metrics for data-mature fleets (dynamic route efficiency, exception resolution velocity, predictive delivery success)
Once the essentials are clean and consistent, these sharper metrics separate good fleets from great ones.
- Dynamic route efficiency score: how close actual route time and distance track the optimised plan, measured continuously rather than at day end. A falling score points to sequencing decay or drivers ignoring the plan.
- Exception resolution velocity: average time from a delivery exception being raised (wrong address, access issue, failed attempt) to it being resolved. Slow resolution turns one problem into a cluster of missed windows.
- Predicted delivery success: the probability a stop lands on time and first-attempt, calculated from live conditions and historical patterns. This is the purest leading indicator there is; it flags at-risk stops before the driver even arrives.
- Communication effectiveness rate: the share of deliveries where a proactive ETA or delay notification was sent and opened. High engagement here is what pulls WISMO down.
Which metrics matter most by industry (pharma, heavy goods, early-morning food)
No single metric ranking fits every fleet. The delivery model decides which KPIs carry the most weight.
| Vertical | Metrics that carry extra weight | Why |
|---|---|---|
| Pharma / prescription delivery | Order accuracy, chain-of-custody visibility, claims rate | Compliance and patient safety leave no margin for wrong or damaged items |
| Heavy goods / site delivery | Claims/damage rate, service time per stop, delivery consistency | Longer dwell, higher handling risk, and site access variability |
| Early-morning food / bakery | On-time within tight windows, first-attempt success, route adherence | Freshness windows are unforgiving; a late run means a wasted product |
| Cold chain / refrigerated | On-time delivery, temperature-safe timing, first-attempt success | Time on the vehicle is a food-safety risk, not just a service issue |
Early-morning delivery windows, the kind a bakery operation like Husk Bakery runs against, make on-time and route adherence the metrics that keep the product fresh and the customer supplied. Set your targets against your own model, not a borrowed benchmark from a different industry.
Common KPI definition mistakes that quietly corrupt your numbers
A metric is only as trustworthy as its definition. These are the mistakes that make dashboards lie.
- No fixed definition of "on time." Same-day and within-the-booked-window are wildly different bars. Pick one rule and hold it across every team before you compare anything.
- Inconsistent failed-delivery codes. If one driver logs "customer not home" and another logs "no access" for the same event, your failure analysis is noise. Standardise exception codes.
- Missing POD data. Gaps in photo, signature, or geo-stamp capture mean disputes get settled by argument, not evidence, and your accuracy and claims numbers drift.
- Unsegmented fleet-wide averages. Blending dense residential routes with long rural runs into one number hides both. Segment by route type, driver, region, and customer.
- Reporting lagging metrics as if they were early warnings. End-of-day on-time rate cannot save today's deliveries. Do not manage the live day off numbers that only settle after it.
How to build a last mile metrics dashboard step by step
- Lock your definitions first. Write down the exact rule for on-time, failed delivery, and order accuracy. This is the foundation; skip it and everything downstream is corrupt.
- Connect your data sources. Pull from the driver app, GPS, scan events, proof of delivery, and customer feedback. Manual spreadsheets break the moment volume rises.
- Set your time windows. Decide the reporting cadence per metric: live for drift and exceptions, daily for on-time and failed delivery, weekly and monthly for cost and CSAT trends.
- Segment everything. Split by route type, driver, region, vehicle, and customer segment so averages cannot hide problems.
- Set alert thresholds on leading metrics. Define the drift or predicted-failure level that triggers a live alert to the dispatcher, so intervention happens mid-shift.
- Fix your review cadence. Daily stand-up on execution metrics, weekly review on quality and cost, monthly on trends and targets. A dashboard nobody reviews is decoration.
Turning lagging metrics into leading ones with a delivery platform
Here is the argument almost no metrics guide makes: the real value of a delivery platform is that it converts lagging metrics into leading ones. Claims rate and CSAT only tell you about failures after they land on the customer. Live route drift, predicted delivery success, and exception alerts let you act while the run is still fixable.
Locate2u is built to do exactly that shift, and it does the full job in one platform rather than the two or three pieces most tools cover. Route optimisation sets a realistic plan; the driver app and real-time tracking surface drift and exceptions live; proof of delivery captures photo, signature, and geo-stamped evidence at the door; and customer notifications cut WISMO before the calls start. It runs cleanly for a one-to-five driver micro-fleet and scales to enterprise volume without re-platforming, handles parcel and heavy goods, and works natively across Australia, New Zealand, the US, UK, and Canada with integrations into Shopify, WooCommerce, ShipStation, Xero, ServiceM8, and Zapier. That combination is what lets a fleet stop reading yesterday's failures and start preventing today's. Explore delivery management or see how operators across verticals run it on our customers page.
FAQs
What are last mile delivery metrics?
Last mile delivery metrics are the KPIs that measure performance on the final leg of delivery, from depot to customer door. Core examples are on-time delivery rate, first-attempt success rate, cost per delivery, order accuracy, customer satisfaction, and average service time per stop. They fall into leading indicators that predict problems and lagging indicators that report them after they happen.
How do you calculate on-time delivery rate?
On-time delivery rate = (number of deliveries completed within the promised time window / total number of deliveries) x 100, measured over a set period such as a day, week, or month. The result depends entirely on how you define "on time", so lock a clear rule (for example within the booked window, not just the same day) before you compare across teams.
What is a good last mile delivery success rate?
A first-attempt delivery success rate of around 90 percent or higher is a common starting target, and mature operations often exceed 95 percent. The right benchmark varies by industry: high-density parcel routes tolerate less variance than heavy-goods or scheduled service runs, so set your target against your own delivery model rather than a universal number.
Which last mile delivery KPI matters most?
There is no single winner, but on-time delivery rate and first-attempt success rate carry the most weight because they drive both cost and customer satisfaction. The bigger shift is moving from lagging metrics you read after a failure toward leading ones like planned-vs-actual route drift and predicted delivery success, so you can act while the run is still fixable.
Note for the site team: the brand style guide failed to load for this draft, so the tone and formatting rules were applied from structural guidance alone. Please confirm the style guide is correctly configured before publishing, as a fresh pass against it will improve quality.