Forecast delivery delays from carrier data
Last updated 11 August 2026
Delivery delay forecasting lets operations teams tell a customer a shipment will be late before it is late, by scoring each consignment against historical lane, carrier and seasonal performance, typically improving arrival estimates by a modest margin and cutting the where-is-my-order contacts that follow a missed date.
What problem this solves
A customer is given a delivery date at checkout that comes from a carrier’s standard transit table. The table does not know that this lane runs late every December, that this carrier has been missing its window for three weeks, or that the consignment already sat in a hub for two days.
The first anyone hears about the delay is when the customer calls on the promised day, and the agent has no better answer than the same table.
How it works
- Assemble shipment history: origin, destination, carrier, service level, weight, promised date and actual delivery date.
- Add the events you already receive — pickup scans, hub arrivals, customs clearance — as each shipment progresses.
- Train a model on which combinations historically ran late and by how much, rather than on the carrier’s published transit time.
- Score consignments in flight and re-score as each new scan arrives.
- Trigger a notification when predicted arrival slips past the promised date, before that date passes.
- Give support agents the same prediction, so the answer on the phone matches the message the customer already received.
What you need to start
- Two or more years of shipment records holding both promised and actual delivery dates
- Carrier tracking events through an API rather than a daily file, or predictions arrive too late to act on
- A customer notification channel and an agreed policy on when to proactively tell someone their order is late
- Agreement on what counts as late, since carrier and customer definitions rarely match
Expected outcomes
Typical ranges, with sources
| Metric | Typical range | Source |
|---|---|---|
| ETA prediction error (MAE) | −12% vs a rules-based system | View source |
| Delivery-related inbound contacts | −40% in one deployment | View source |
| Delay-duration prediction error | 0.67–0.91 days on 10M+ records | View source |
Real-world signal
Emerging evidence · 2 publishers
Hapag-Lloyd replaced a rules-based vessel ETA system with a machine learning model and reported roughly 12% lower mean absolute error, which it says translated into climbing two positions in the international schedule-reliability ranking.
aws.amazon.com · 2025 ↗Aramex trained a transit-time model on 6.3 million historical shipments and reported a 74% improvement in delivery-prediction accuracy and a 40% fall in call-centre volume. The post does not define the accuracy baseline.
aws.amazon.com · 2021 ↗On more than 10 million real shipment records from a logistics provider, a multi-task deep learning model predicted delay duration to within 0.67–0.91 days mean absolute error, 15–64% better than tree-based baselines.
arxiv.org · 2026 ↗
Common questions
How much data do you need to start?
Two years of shipments carrying both the promised and the actual delivery date. The actual date is the part most companies find they have not stored reliably, and without it there is nothing to train against.
What happens on lanes with little history?
The model will be poor there and should say so. Fall back to the carrier’s published transit time and mark the prediction low-confidence rather than showing a number you do not trust.
How long does it take to get running?
Assembling clean shipment history is usually months rather than weeks. Getting carrier events by API instead of batch file is the other common blocker, and it is worth resolving before any modelling starts.
What these scores mean
How this use case was rated, and against what
| Dimension | Rating | What that means |
|---|---|---|
| Impact | Moderate3/5 | Meaningful savings for one team |
| Implementation effort | High4/5 | Custom build, about a quarter |
| Data requirement | Advanced4/5 | Needs history across two systems |
| Company size | 201–1000 · 1000+ | |