Late deliveries spotted hours before they happen. Customers told first, with real options to rebook, customer service warned before the calls start, and planners shown where the day is going wrong.
At a glance
An illustrative scenario. The numbers are typical examples, not a client case study. The cloud services and UK rules were checked on 9 November 2026.
Most networks know a parcel will be late long before the customer does. The trunk lorry left the hub forty minutes behind. A depot is over capacity after a bank holiday. A driver's route has two road closures on it and a forecast of heavy rain. The signs are all in the data: telematics, scan events, the route plan, the depot's sort figures. Nobody joins them up in time, so the customer's first warning is a delivery window that passes without a knock.
What follows is expensive. Customers contact the retailer, which contacts the carrier. Where-is-my-parcel enquiries are often a third or more of inbound contacts in a typical network, and each one is answered by a person looking up the same scans the customer could have been sent. Failed first attempts mean a second trip. Planners spend the afternoon reacting to calls from drivers rather than moving work before it goes wrong.
Regulators are watching too. In its October 2026 parcel survey, Ofcom found that delays were the most common delivery problem, reported by 32% of recipients, and said it is considering whether stronger regulation is needed. For a retailer, the Consumer Rights Act 2015 means late delivery is its problem, whoever drives the van. Telling people early, honestly, and with a real choice of what happens next is good service and good risk management.
Agree these, and measure the baseline, before anything is built. Example targets are typical, not promises.
Inbound calls, chats and emails asking where a delivery is, per thousand parcels.
ExampleDown by a third
How long before the original window customers hear about a delay.
ExampleAt least 2 hours for most predicted delays
Of parcels flagged as late, how many were; of late parcels, how many were flagged. Too many false alarms and customers stop trusting the messages.
ExampleAgreed limits for both, reviewed weekly
Parcels delivered on the first attempt, including those rebooked by the customer after a warning.
ExampleUp 2–4 points
How many updates each customer gets. More isn't better: one clear message beats five vague ones.
ExampleNo more than two delay messages per parcel
Delay complaints and contact satisfaction, split for customers who've told you about an accessibility need.
ExampleFalling, and no group worse off
Cross-sector rules are on the UK regulation map.
The retailer must deliver at the agreed time, or within 30 days if nothing was agreed. If an agreed date was essential, the consumer can treat the contract as ended when it's missed. Risk stays with the retailer until the goods reach the consumer or someone they've named. So the rebooking options must be the customer's choice, recorded, and a neighbour or safe place is only used when the customer or the retailer's terms allow it. The AI never refuses, cancels or refunds; people and the retailer's own processes do.
A delay update the customer needs is a service message. Add a discount code, a 'shop again' link or a promotion and the whole message can become direct marketing, with consent rules attached. Since 5 February 2026, PECR fines can reach £17.5 million or 4% of global turnover. Templates are owned by compliance and stay strictly informational.
If you're a parcel operator, Ofcom's rules require fair complaints handling and published policies for treating disabled customers fairly. Accessibility needs the customer has shared, such as needing more time to reach the door, are carried into every rebooking option and into the heads-up queue. Ofcom has said it may strengthen these protections.
Lorries over 3.5 tonnes follow the assimilated rules, recorded on the tachograph; most vans follow the GB domestic rules. Since 1 July 2026, vehicles over 2.5 tonnes carrying goods between the UK and the EU for hire or reward need a smart tachograph version 2. A predicted delay is never solved by suggesting a driver works longer: the planner assistant reads each driver's remaining legal driving time and plans within it.
Telematics data identifies drivers, so it's personal data. Drivers are told what's collected and why, private use of vehicles is excluded, and a DPIA is done with driver representatives involved. Data collected to predict delays isn't quietly reused to rank or discipline drivers. Any decision about a driver's performance is a separate, documented process, made by a manager, with the automated decision safeguards in place since 5 February 2026.
Since 6 April 2025, the CMA can fine firms directly for breaches of consumer law, up to 10% of global turnover. Delivery promises and revised windows must not mislead. The system only gives a new window when the model's confidence meets an agreed threshold, and otherwise says plainly that a time will follow.
Showing AWSAzuresovereign / on-prem services. Switch with the toggle; every diagram and table on this page follows it.
01Channels
02Intake
03Intelligence
04Orchestration
05Systems of record
06People
| Layer | AWS | Azure | Sovereign / on-prem |
|---|---|---|---|
| Event intake: scans, telematics, partnersMost telematics arrives through your telematics provider's API, not straight from the vehicles. AWS IoT FleetWise and Timestream for LiveAnalytics are closed to new customers, so don't design around them. | Amazon Kinesis Data Streams, API Gateway, S3 | Azure Event Hubs, API Management, Blob Storage | Apache Kafka, Kong or your existing API gateway, Ceph or IONOS S3 Object Storage |
| Real-time featuresTurns raw events into features: minutes behind plan, stops left, depot backlog, time since last scan. | Amazon Managed Service for Apache Flink | Azure Stream Analytics, or Real-Time Intelligence in Microsoft Fabric | Apache Flink on Kubernetes |
| Routing and trafficAzure Maps Route v1 and Traffic v1 retire on 31 March 2028, so build on the current versions. Azure Maps keeps request data in its EU or US geography, not a UK-only one; record that in the DPIA. | Amazon Location Service (Routes API), available in eu-west-2 (London) | Azure Maps Route (version 2025-01-01) and Traffic | Open-source routing (e.g. Valhalla or OSRM) on OpenStreetMap, plus National Highways' traffic data and a licensed traffic feed |
| WeatherForecasts at depot and route level are enough. Check the licence covers commercial, operational use. | Met Office Weather DataHub (site-specific forecasts) | Azure Maps Weather, or Met Office Weather DataHub | Met Office Weather DataHub |
| Delay prediction (custom ML)A gradient-boosted model on your own history usually beats anything cleverer. Amazon Forecast is closed to new customers; build in SageMaker AI. | SageMaker AI | Azure Machine Learning | MLflow and Kubeflow on Kubernetes |
| Message drafting and reasoningThe model fills approved templates and explains hotspots to planners. Both clouds offer a choice of models, including Claude. | Amazon Bedrock | Microsoft Foundry | Open-weight models served with vLLM on your own GPUs, or IONOS AI Model Hub |
| Agent runtimeThe original Bedrock Agents closed to new customers on 30 July 2026; new builds use AgentCore. | Amazon Bedrock AgentCore | Foundry Agent Service | An open-source agent framework (e.g. LangGraph) on Kubernetes |
| WorkflowOne workflow per at-risk consignment: warn, offer options, record the choice, update the plan. | AWS Step Functions | Logic Apps or Durable Functions | Temporal, or n8n |
| Middleware and events | Amazon EventBridge, SQS | Event Grid, Service Bus | Apache Kafka or RabbitMQ |
| Customer messagingAmazon Pinpoint reached end of support on 30 October 2026; its SMS features continue as AWS End User Messaging. Often the retailer sends the message under its own brand, through your API. | AWS End User Messaging (SMS), Amazon SES (email) | Azure Communication Services (SMS and email) | Your existing SMS gateway and mail server |
| Link to TMS, WMS and retailersReuse the status messages and EDI flows you already exchange with retailers. Don't build a parallel channel. | API Gateway, plus your existing EDI or integration platform | API Management, plus your existing EDI or integration platform | Kong or your existing API gateway, plus your existing EDI or integration platform |
| Human viewsAgents and planners work where they already work. A hotspot map can sit in your BI tool or the planning system. | In the existing case tool and planning screens | In the existing case tool and planning screens | In the existing case tool and planning screens |
| GuardrailsBlocks promotional content, promises of compensation, and anything outside the approved templates. | Bedrock Guardrails | Foundry guardrails (Azure AI Content Safety) | Open-source guardrails (e.g. NeMo Guardrails, Llama Guard) |
| Identity, keys, data protectionDriver identifiers are pseudonymised before they reach the model. | IAM Identity Center, KMS, Macie | Entra ID, Key Vault, Purview | Keycloak or your existing Active Directory; OpenBao or HashiCorp Vault; an HSM |
| Monitoring and auditLog every prediction, every message sent, every customer choice and every planner decision. | CloudWatch, CloudTrail | Azure Monitor, Log Analytics | Prometheus, Grafana, OpenTelemetry |
| UK data residencyIONOS AI Model Hub runs in German data centres: EU, not UK, residency. | eu-west-2 (London) | UK South / UK West, noting Azure Maps' EU geography | Your own UK data centre, or a UK or EU provider |
On a phone, the table shows the platform you pick. Sovereign / on-prem means open, portable components you can run in your own data centre or with a UK or European provider; IONOS is shown as one example, and others exist. What sovereign cloud means →
Many organisations keep core systems and sensitive data on their own servers. This is how the same design works across both.
Stays on-prem
The transport management system, depot sortation and WMS, the tachograph analysis software and the handheld back end stay where they are. In many networks these run in the company's own data centre or at each depot, and nothing here needs them to move.
Uses cloud AI
The event stream, the delay model, routing and traffic lookups, message drafting and the two agents run in AWS or Azure, or on your own Kubernetes and GPUs for the sovereign option. Only consignment, route and pseudonymised vehicle data is sent, never driver names.
How they connect
A private link (AWS Direct Connect or Azure ExpressRoute) from the data centre, and the API layer. Depots publish scan events onto the queue as they do today, and predictions come back as events the TMS and case tool can read.
If the link drops
Parcels keep moving and customers get the standard tracking messages the TMS already sends. Planners work from their usual screens. Events queue on your side and the model catches up when the link returns, without re-sending messages for deliveries that have already happened.
What each agent may do through its tools, what it may not, and where a person signs off. The limits are enforced by the platform, not the prompt.
Customer update agent
Where a person signs offPeople decide refunds, compensation, cancellations, claims for lost or damaged goods, and any complaint response. The agent's permissions are enforced by the platform's identity and policy controls, not by instructions in a prompt.
Planner assistant
Where a person signs offThe planner decides every change to the plan and makes it in the TMS. Depot managers decide anything that affects a driver's day.
The TMS stays the source of truth for the plan, and the handhelds and sortation system stay the source of truth for scans. The AI reads both through an API layer and events, and writes back only one thing: the customer's rebooking choice, through the same API the retailer portal uses.
Retailers already exchange status messages with you, by API or EDI. Predicted delays go out the same way, as a new status with a reason code, so a retailer can send the message under its own brand if its contract says so. Agree in discovery who sends which message, so the customer never hears twice.
Every consignment has one delay workflow, keyed on its ID. Duplicate scans, late telematics and retries never create a second message. Messages are suppressed once a parcel is out for delivery and on time again, or delivered, and quiet hours apply.
A switch turns proactive messages off by retailer, depot or the whole network. If the model misbehaves on a bad-weather day, customers fall back to the standard tracking messages within minutes.
Map the scan, telematics and status flows, measure baseline contacts and first-time delivery, check data quality by depot, agree who sends which message with the main retailers, and start the DPIA with driver representatives.
Gate · must be true to passBaseline agreed, data feeds confirmed, message ownership agreed, DPIA started, drivers' representatives briefed.
Two or three depots in shadow mode first: the model predicts, nobody is messaged, and predictions are compared with what happened. Then messages to one retailer's customers.
Gate · must be true to passPrediction quality within agreed limits at every pilot depot, message templates signed off, no rise in complaints.
Proactive messages, the heads-up queue and the planner view go live in the pilot depots, with monitoring, the off switch and a rollback plan.
Gate · must be true to passMonitoring, support model, peak thresholds, rollback plan and staff training in place.
Add depots in waves and retailers one at a time, then pallets and two-person deliveries, which need their own rules.
Gate · must be true to passEach new depot passes the same shadow-mode gate before customers are messaged.
| Activity | Operations director | Product owner | Solutions architectI can fill this | Technical PMI can fill this | EngineersI can fill this | Customer service lead | Compliance & DPO | SecurityI can fill this |
|---|---|---|---|---|---|---|---|---|
| Business case and benefits | Accountable | Responsible | Consulted | Consulted | Informed | Consulted | Informed | Informed |
| Target architecture and TMS integration | Informed | Consulted | Accountable and Responsible | Consulted | Consulted | Informed | Consulted | Consulted |
| Retailer message ownership and status flows | Accountable | Responsible | Consulted | Responsible | Consulted | Consulted | Consulted | Informed |
| DPIA, driver consultation and PECR review | Consulted | Consulted | Consulted | Informed | Informed | Informed | Accountable and Responsible | Consulted |
| Build and integration | Informed | Consulted | Accountable | Responsible | Responsible | Informed | Informed | Consulted |
| Shadow-mode testing by depot | Consulted | Accountable | Responsible | Responsible | Responsible | Consulted | Informed | Informed |
| Go-live decision | Accountable | Responsible | Consulted | Responsible | Informed | Consulted | Consulted | Consulted |
| Run, monitor and improve | Accountable | Responsible | Consulted | Consulted | Responsible | Responsible | Consulted | Consulted |
R ResponsibleA AccountableC ConsultedI Informed· not involved
Option A
If there's no architect on the programme, I'd own the design end to end: the event flows from depots and vehicles, the delay model, the integration with your TMS and the retailers' status messages, and the gates. I'd start with the scan data and the message flows you already have, because that's where the early warnings are. I'd report to your programme board.
Option B
If your partner or your own team already has an architect, I'd take on the event pipeline, the prediction model and the TMS and retailer integration under their lead, and give them a second senior opinion on data protection for driver data, messaging and what happens at peak.
Goes wrong
The model was trained on a quiet month. On the first snowy Friday in December, it flags half the network and customers get a flood of messages.
How the design avoids it
Train on at least a full year including peak, set thresholds per season, cap messages per parcel, and keep the off switch one click away.
Goes wrong
Scan data is patchy at some depots, so the model learns their gaps, not their delays.
How the design avoids it
Check data quality by depot in discovery, and only switch messages on where shadow mode proves the predictions.
Goes wrong
Customers hear twice, once from the retailer and once from the carrier, with different windows.
How the design avoids it
Agree message ownership per retailer in discovery and send one status with a reason code through the flows you already have.
Goes wrong
Telematics collected for delay prediction becomes a driver league table without anyone deciding it should.
How the design avoids it
A written purpose in the DPIA, pseudonymised driver IDs in the model, and a separate, consulted process for any performance use.
Goes wrong
A revised window becomes a promise the network can't keep, and the second miss does more harm than the first.
How the design avoids it
Only give a time when confidence meets the threshold, otherwise say a time will follow, and measure how often revised windows are met.
Changes already announced or under way that affect this design. More in the UK horizon scan.
Keep clear records of proactive contact, complaints and accessibility needs by depot, so you can show how delays are handled whatever the new rules say.
Keep the prediction log, the message log and the planner decisions in a form you could show the ICO, for both customers and drivers.
On Azure, build on Route 2025-01-01 and the current traffic APIs from the start, and check any existing route planning tools for v1 calls.
Audit every vehicle unit and handheld now, and plan replacements into the fleet cycle. A vehicle that goes silent looks like a delay to the model.
Good answers are specific. Vague answers to any of these are worth following up.
Whether you need someone to lead the design or to support the architect you already have, let's talk it through.
