Predictive Analytics for Last-Mile Operations

Predictive analytics has a branding problem. The term arrives attached to neural networks, data scientists and enterprise platforms, and a business running eleven stops on a Tuesday reasonably concludes it isn’t for them.

It is, though, in a smaller form than the marketing suggests. Predictive analytics for last-mile operations starts with data you already have: order timestamps, requested windows, route completion times and delivery outcomes. From those four things you can answer questions that change next week’s decisions. How many stops should I plan for? Which of Thursday’s deliveries is likely to run past its window? Which account is quietly on its way out?

None of that needs a model you couldn’t build in a spreadsheet. What it needs is consistent history, which is why this sits downstream of keeping a proper customer record for each delivery account. A forecast is only as good as the record it’s calculated from.

The Bottom Line

• Four data points carry most of the value: order timestamp, requested window, actual delivery time, and outcome (completed, late, failed).
• Route volume is the easiest forecast and the most useful. Day-of-week averages over eight weeks beat intuition immediately.
• Failed first attempts are the most expensive predictable event in last-mile work. Roughly 5% of deliveries fail on first attempt at an average $17.78 each (Locus).
• The last mile absorbs a large share of total shipping cost, with industry estimates in the 41–53% range, so small percentage improvements here move real money.
• Eight weeks of clean history makes a usable forecast. Twelve months makes a seasonal one. Three weeks makes a guess with decimal places.

What predictive analytics means in a last-mile operation

In its general form, predictive analytics uses historical data with statistical modelling to estimate future outcomes. In a delivery operation, that general definition collapses into four concrete questions, and it’s worth naming them because they need different data and different responses.

• Volume: how many stops, cases or drops are coming, by day.
• Timing: which deliveries are at risk of missing their window.
• Failure: which stops are likely to need a second attempt.
• Attrition: which accounts are likely to reduce or stop ordering.

Larger logistics operations run all four continuously, using timestamps, GPS traces, proof-of-delivery records and customer feedback to find bottlenecks before they cost anything. The mechanism is not the point. What matters is that a small operation generates the same four data types, just fewer rows. Hundreds of orders is enough to find a pattern. You are not training a model; you are calculating averages against a baseline and noticing when reality departs from it.

This is also where a delivery business finally gets paid back for record-keeping. The same history that tells you an account is lapsing is what feeds the volume forecast, which is part of why choosing a system that actually stores order history matters. The CRM software comparison for operations that deliver their own orders scores products on exactly that.

The delivery data you need before any prediction works

Most small operations already produce this data and then throw it away, either by not exporting it or by overwriting it.

Two practical notes. Record actual delivery times from proof-of-delivery timestamps rather than driver recollection, which compresses toward “on time” and destroys the lateness signal you’re trying to find. And keep failed attempts as rows, not as deletions. An operation that quietly re-delivers and overwrites the record has erased its most expensive dataset.

Forecasting next week’s route volume

Start here. It’s the simplest calculation in the post and it pays back fastest.

Take eight weeks of orders and average them by day of week. That’s your baseline. Then adjust for the three things that reliably distort it:

• Known calendar events. Public holidays, local market days, the week a large account closes for refurbishment.
• Trend. If the last four weeks average 12% above the previous four, carry that forward rather than using the flat eight-week mean.
• Account-level changes you already know about. A new account starting Monday, or one you know has halved its order.

The output is a number of stops per day for next week, with a range. Plan capacity against the top of the range, not the middle. The cost of being one van short on a Friday is much higher than the cost of an hour of slack.

Accuracy here is not the point. Being roughly right a week in advance beats being precisely right on the morning, because a week is enough time to add a driver and a morning isn’t.

Predicting which deliveries will run late

Lateness is not random, and in most operations it concentrates in a small number of identifiable places. Sort your delivery history by how far each drop landed from its requested window, then look for concentration along four axes:

• By time of day. Almost every operation has a window where lateness spikes, usually the one straddling local rush hour or a lunchtime access restriction.
• By stop position in the route. If stops nine through twelve are consistently late, the route is over-planned, not the driver slow. Your real capacity is eight.
• By address. A handful of addresses will account for a disproportionate share: tower blocks, pedestrianised streets, sites with a single loading bay.
• By order size. Large drops take longer to unload than the route plan assumes, and the error compounds down the route.

Each of those has a different fix, which is the reason to separate them rather than tracking one lateness percentage. Time-of-day concentration is a scheduling fix. Stop-position concentration is a capacity fix. Address concentration is an access-notes fix. Order-size concentration is a planning-parameter fix.

The prediction, once you’ve done this, is unglamorous and effective: before the route goes out, flag any stop that matches two or more known risk factors and either resequence it or warn the customer. A warned customer who gets a late delivery is far less damaged than a surprised one.

Predicting failed first attempts

This is the most expensive predictable event in last-mile work. Around 5% of deliveries fail on the first attempt at an average cost near $17.78 each, and the direct cost understates it. A failed stop is paid for twice in driver time, fuel and dispatch overhead, and it usually drags a support contact along behind it (Locus failed-delivery cost framework).

Failures are highly predictable because they repeat. The signals worth scoring:

• Address history. An address that has failed twice will fail again. This alone catches a large share.
• Delivery time versus opening hours. Arrivals near the start or end of a site’s opening window fail far more often than mid-window ones.
• Missing or stale contact details. No mobile number on the account is a measurable risk factor, because the recovery path when the driver arrives to a locked door doesn’t exist.
• First-ever delivery to a new account. No access notes yet, nobody expecting the van.

Turn those into a simple flag rather than a score: any stop with two or more gets a confirmation message the evening before. The economics are not close. A message costs nothing and a failed attempt costs around $17 plus a second visit.

Given the last mile absorbs somewhere in the region of 41–53% of total shipping cost, a few percentage points off your failure rate is one of the larger cost levers available to a small operation, and it needs no new equipment.

Spotting accounts that are about to stop ordering

Attrition is a prediction problem with an unusually clear signal: the reorder gap. For each account, calculate the median days between orders over the last six months, then compare today’s days-since-last-order against it.

• Under 1.5× the median: normal variation.
• 1.5× to 2×: watch. Holidays explain most of these, but not all.
• Over 2×: treat as at-risk and call.
• Order size falling 30%+ while frequency holds: the most under-read signal in the whole dataset. This is a customer trialling a second supplier, and it precedes a full stop by weeks.

The reason this works better than a revenue report is timing. Revenue reports show the loss after the quarter closes; the reorder gap shows it within days. And it’s predictive rather than descriptive. An account at 2.2× its median gap has not yet told you anything, and is the only point at which a phone call can still change the outcome.

Pair this with delivery quality data, because the two are connected. Accounts that have had two or more exceptions in a fortnight churn at visibly higher rates than accounts that haven’t, so an exception cluster is an early-warning signal in its own right.

How much history you need before a forecast is trustworthy

A short honest table, because this is where small operations are most often misled.

The failure mode to avoid: producing a seasonal forecast from three months of data, watching it be wrong, and concluding predictive analytics doesn’t work at your size. It works; it just can’t see a pattern that isn’t in the file yet.

Doing this in a spreadsheet versus buying software

For most operations under a few hundred stops a week, a spreadsheet is the right tool and will stay that way for years. One weekly export, a fifteen-minute review, and four pivot tables: volume by day, lateness by hour, failures by address, reorder gap by account. That covers everything above.

Software earns its place at two thresholds: when the export itself becomes a chore, and when you want the flags to reach people automatically rather than waiting for someone to look. At that point what you want is not a “predictive analytics platform” but a delivery system that records the raw material properly and a CRM that holds the account history. Metrobi’s proof-of-delivery photos, real-time tracking and delivery notifications produce timestamped outcome records as a by-product of running routes, which removes the most tedious part of this, getting reliable actual-delivery times without anyone transcribing them.

Be sceptical of headline efficiency claims in this category. Vendor figures of 20–45% improvement come from large enterprise deployments with dedicated teams, and they do not transfer cleanly to an operation with two vans. The gains available to you are real but differently shaped: fewer failed attempts, better-sized routes, and earlier calls to lapsing accounts.

Where predictive analytics goes wrong in small operations

• Forecasting the wrong thing. Predicting revenue is a finance exercise with its own methods. Predicting stops, lateness and failures is an operations exercise, and it’s the one that changes what you do on Monday.
• Chasing precision. A forecast that’s 10% out but arrives a week early is worth far more than one that’s 2% out and arrives Friday afternoon.
• Letting the data go inconsistent. Two months where nobody recorded failed attempts properly will quietly poison every calculation built on that period.
• Building a dashboard nobody reads. Four numbers reviewed weekly by a named person beats twenty numbers on a screen.
• Ignoring what you already know. If you know a large account is closing for two weeks in August, that beats any model. Override the forecast; don’t let it override you.

Frequently asked questions

Do I need machine learning for any of this? No. Every forecast described here is an average, a median or a concentration count. Machine learning becomes relevant at volumes where patterns are too numerous to eyeball, which is well above a typical local delivery operation.

What’s the single best place to start? Day-of-week volume from eight weeks of orders. It takes about twenty minutes, and most operators find at least one day where their intuition was consistently wrong.

How is this different from tracking delivery metrics? Metrics describe what happened; these calculations estimate what will happen. Both use the same data, but a metric tells you your failure rate was 6% last month, while a prediction tells you which of tomorrow’s stops is likely to be part of this month’s.

Can I predict lateness without GPS tracking? Yes, if you have proof-of-delivery timestamps. GPS traces add detail about where time is lost, but arrival times alone are enough to find concentration by hour, stop position and address.

How often should I redo the forecast? Weekly for volume, monthly for lateness and failure patterns, and quarterly for the seasonal view. Reforecasting daily produces churn without insight.

Start with one number

Pick the volume forecast. Export eight weeks of orders, average by day of week, and write next week’s expected stop count on the wall before the week starts. Then compare it on Friday.

Do that four times and two things happen: you find out where your intuition is unreliable, and you start keeping the underlying data properly because now something depends on it. Every other prediction in this post is built on that same file, which means the hard part isn’t the forecasting, it’s the eight weeks of consistent records that come first.

Sources: Locus failed first-attempt delivery cost framework · Locus last-mile delivery analytics · SmartRoutes last-mile delivery statistics