ETA & delivery-time prediction

"Where is my truck, my container, my parcel, my technician?" Plans and static transit times say little about the actual arrival. Traffic, border and ferry queues, driver rest periods, unloading at the previous stop, port congestion and weather all shift it. ETA prediction learns from millions of completed trips how these factors turn a routing-engine estimate into a realistic arrival time, and it keeps the estimate up to date as the shipment moves. The result feeds dock and yard planning, production supply, customer notifications and exception management. In 2026 the technique is mature: the main levers are data coverage (carrier connectivity) and good uncertainty estimates, not a better model. LLM agents now act on ETA changes (see AGENT-024), but the ETA itself is still a classic ML problem.

Problem & value

• Today: shippers and receivers phone carriers for status, plan dock slots on booked times and find out about delays when the truck fails to show up. E-commerce shows generic "2–4 working days" promises. Field-service customers wait at home for a four-hour window. Ocean ETAs from carrier schedules often change many times per voyage.
• AI value: fewer status calls, earlier exception handling, better dock and labour planning, less detention/demurrage, narrower customer time windows and higher conversion when a credible delivery date is shown at checkout.
• Evidence at scale: Google Maps' ETAs were already accurate for over 97% of trips. A graph neural network developed with DeepMind still improved ETA accuracy by up to 50% in cities such as Berlin, Sydney and Tokyo [1]. The CIKM paper reports that negative ETA outcomes fell by more than 40% in cities like Sydney compared with the previous production model [2]. Uber replaced one of the largest XGBoost ensembles of its time with a transformer that predicts the residual on top of the routing engine. That model became Uber's highest-QPS model [3][4].
• Vendor-reported results (not independently verified): visibility platforms publish case results such as large cuts in detention costs or exception response times [6][8]. Treat them as upper bounds and measure your own baseline.

Variants

• Road freight FTL/LTL (shipper or receiver view): ETA per load from telematics or carrier data via a real-time transportation visibility (RTTV) platform. It drives dock and time-slot management and just-in-time/just-in-sequence supply in automotive.
• Last-mile parcel & grocery: predicted delivery window per stop from route sequence, service times and courier behaviour. The narrowed window is pushed to the recipient.
• Delivery-promise / delivery-date estimation (pre-purchase): predicts the delivery date at checkout from warehouse cut-offs, carrier performance and lane history (e-commerce, spare parts).
• Food, quick commerce & ride-hailing: promise time made up of preparation, pickup and travel, with sub-second latency and millions of requests.
• Ocean & air cargo: vessel/container ETA from AIS, port congestion and carrier schedules. For air freight, milestones are used. Port and terminal slot planning is in OPT-037.
• Rail and public transport: real-time arrival prediction for passenger information (GTFS Realtime/SIRI). Recovery planning after disruption is in OPT-020.
• Field service: technician arrival time from the current job's predicted remaining duration plus travel (dispatch itself: OPT-019).
• Private use: navigation-app ETAs and parcel-tracking apps. Consumers use this through products and do not build it themselves.
• Not in scope: case-level delay prediction in business processes from event logs (PRED-024), project schedule overruns (PRED-023), and the agent that books carriers and handles the exceptions (AGENT-024).

How it works

1. event & position stream (GPS/ELD, carrier API/EDI, AIS, scans)
2. cleansing & map-matching (snap pings to road network, detect stops/dwell, dedupe events)
3. routing engine baseline (remaining distance & traffic-aware drive time per leg)
4. feature build (time of day/week, lane & carrier history, site dwell stats, driver-hours left, weather, border/ferry queues, live delay vs. plan)
5. ML residual model (GBDT or transformer)
6. ETA point estimate
7. uncertainty layer (quantile loss or conformal calibration)
8. P10/P50/P90, P(late)
9. business rules (delay > threshold
10. alert, slot reschedule, customer message)
11. feedback loop: actual arrival vs. predicted
12. monitoring & retraining

• Baseline + residual is the dominant production pattern. A routing engine computes segment-wise travel time along the best path, and ML learns the difference to observed outcomes. Uber calls this "ETA post-processing", because the model is easier to change than the routing engine [3][4].
• Graph models capture spatial spillover in the road network (Google's supersegment GNN [1][2]). For most companies, buying traffic-aware routing (Google, HERE, TomTom, PTV) gives them this without training their own model.
• Dwell and service time at stops is often the largest error source in freight and last mile. It is learned per site, customer and time of day.
• Hours-of-service: EU driving and rest-time rules (Regulation (EC) 561/2006) add deterministic breaks that must be simulated, not learned.
• Human-in-the-loop: dispatchers confirm or override exception alerts. Customer-facing promises use a conservative quantile (e.g. P80/P90) rather than the median.

Data preparation

The model needs planned routes, stops and time windows (TMS, route planner, ERP orders), live positions (telematics, driver app, carrier APIs or EDI messages) and the history of completed trips with planned versus actual arrival. These sit in the TMS, in telematics portals, in carrier e-mails and Excel sheets, and sometimes only on paper delivery notes.

Typical gaps: inconsistent address data, missing geocoordinates, GPS pings with holes, no recorded unloading and dwell times, stop events entered by drivers days later, and different status codes per carrier. Access rights to carrier and telematics data are often held by external suppliers.

Preparation steps: - Inventory sources and agree data access with carriers (PREP-001, PREP-005). - Clean and geocode addresses; merge duplicate customer and site records. - Map carrier status codes to one scheme (PREP-019). - Compute dwell and service times per site from history. - Define a reliable "actual arrival" label from existing records (PREP-020). - Build an evaluation set of past trips (PREP-018).

Tools: geocoding services, pandas or dbt, a small data store. Share of total effort: about 40 percent. For addresses and master data see DATA-007.

Implementation paths

Which path for whom

• smb (A): Tracking and ETA modules of TMS, telematics and carrier platforms are mature, EU-hosted and priced per vehicle.
• enterprise (B): ETA is part of a core logistics process and must integrate with own TMS, WMS and carrier feeds, which no single product covers.
• developer (B): Routing and traffic APIs plus a small tabular model give the fastest build with little operations effort.
• public (C): Open-source routing (OSRM, Valhalla, OpenStreetMap) on own or sovereign infrastructure avoids lock-in and procurement problems.
• private (A): Navigation and parcel-tracking apps already provide ETAs.

Path A — Buy (recommended for most SMBs and shippers)

• Real-time transportation visibility platforms: Shippeo (France, a Leader in the 2025 Gartner Magic Quadrant for RTTV, EU-focused) [5], Transporeon Visibility incl. Sixfold (Germany/Austria, part of Trimble, 210,000+ connected carriers and LSPs) [7], project44 Movement [6], FourKites [8], Descartes MacroPoint, and Agheera (Germany, telematics aggregation). They all provide predictive ETAs, and most now add AI agents for exceptions [5][6][8].
• Ocean/container: Portcast (predictive ETAs/ETDs over 12,000+ ports) [9], project44, Kpler MarineTraffic, Vizion.
• Last mile & e-commerce: parcelLab (Munich, predicted delivery dates and post-purchase communication), Bringg, Onfleet, and the route-planning suites of PTV Group (Karlsruhe) and Wise Systems with dynamic ETAs.
• Telematics/TMS built-in: most fleet telematics vendors and TMS systems (e.g. SAP TM with visibility partners) show an ETA. That is often enough for own fleets.
• Choose A when: you are a shipper/receiver with many carriers, since carrier connectivity is the hard part and the vendor network solves it. Check EU hosting, a DPA, carrier-onboarding effort and the ETA-accuracy SLA definition.

Path B — Build on cloud APIs

• Traffic-aware routing APIs as the baseline: Google Routes API (traffic-aware routes, route matrix, truck attributes such as dimensions, weight and hazmat) [10], HERE Routing (Netherlands/ Germany), TomTom Routing (Netherlands), PTV Developer (Germany), Azure Maps, Amazon Location Service.
• ML residual model on your own trip history with managed ML: Vertex AI, SageMaker or Azure ML in EU regions, or STACKIT/OVHcloud for sovereign hosting.
• Streaming: Kafka/Confluent or cloud pub/sub for position events. The ETA is recomputed on each event or every few minutes.
• LLM layer (optional): turn ETA changes into customer messages or dispatcher summaries with an EU-hosted LLM (e.g. Mistral, or Claude/Gemini/GPT in EU regions). The LLM must not compute the ETA itself.
• Choose B when: you run your own fleet or a delivery platform and the ETA is part of your product.

Path C — Self-host (open source)

• Routing engines: Valhalla (MIT; matrices, map matching, time-based routing) [11], OSRM (BSD-2; fast table/matrix service) [12], GraphHopper (Apache-2.0, Germany), all on OpenStreetMap. Load your own historical speed profiles where supported.
• Models: LightGBM/XGBoost/CatBoost with quantile objectives for the residual. TabPFN (Prior Labs, Germany) suits small tabular datasets. Time-series foundation models (Chronos, TimesFM) forecast dwell or lane transit times. Use MAPIE or another conformal-prediction library for calibrated intervals.
• Stack: Kafka/Redpanda + Flink or Python consumers, PostGIS, a feature store (Feast) and MLflow. Serve the model with ONNX Runtime or a simple FastAPI service.
• Hardware: HW1. GBDT inference and OSRM/Valhalla run on CPU servers. A routing engine for Europe needs a server with plenty of RAM for the graph. GPUs only pay off for large deep or graph models.

Path D — Custom training

Worth it for platforms with millions of trips: ride-hailing, food delivery, parcel networks and large carriers. Typical choices are deep residual networks or transformers over tokenised features [3][4], GNNs over the road graph [2], and multi-task models that predict prep, travel and dwell jointly. You need a long, clean history of planned vs. actual events with positions. Public research data includes LaDe, the last-mile delivery dataset from Cainiao (about 10.7 million packages from 21k couriers, with route-prediction and ETA benchmarks) [13][14]. For shippers with a few thousand loads per month, a GBDT residual model on top of an API baseline is usually as good as a custom deep model.

State of the art (2026)

• Production pattern: a traffic-aware routing engine + a learned residual + calibrated uncertainty. GNN-based traffic models (Google) and linear-attention transformers (Uber) mark the high end [1][3].
• Probabilistic ETAs: quantile losses and conformal prediction are standard. Platforms report P(late) and use asymmetric losses because late arrivals cost more than early ones [3].
• Visibility networks + agents: RTTV vendors bundle ML ETAs with AI agents that chase missing carrier status, reschedule dock appointments and answer "where is my order" questions. Examples are FourKites' Tracy and Alan agents and project44's agentic workflows [6][8].
• Regulatory data push: the EU eFTI Regulation (EU) 2020/1056 lets authorities accept electronic freight information from certified platforms from 2026 and makes acceptance mandatory from 9 July 2027. This increases digital, machine-readable transport events [15].
• Limits: ETAs are only as good as position coverage. Missing pings, carriers without telematics and manual status updates dominate the error in freight. Rare disruptions (strikes, closures, canal blockages) are out of distribution. Models trained before a network change drift quickly. Dwell time at unknown sites is hard to predict, and accuracy figures are not comparable across vendors without a shared definition (e.g. "within ±60 min at 4 h before arrival").

Shared resources & combinations

• Same routing/geo stack (routing engine + map data + streaming): OPT-001 vehicle routing, OPT-019 field-service dispatch, OPT-028 ridepooling. One self-hosted Valhalla/OSRM/GraphHopper instance and one GPS event pipeline can serve all of them, and ETA prediction supplies their realistic travel and service times.
• Same tabular-ml/time-series stack: PRED-001 demand forecasting, PRED-019 traffic & mobility demand, PRED-024 predictive process monitoring. They share a feature store, MLflow, conformal intervals and a CPU (HW1) serving tier.
• Upstream signals: PRED-017 weather forecasts, ANOM-011 supplier/supply-chain risk events and DOC-006 extracted logistics documents (status, POD).
• Downstream consumers: AGENT-024 freight operations agent, OPT-037 port and terminal slots, OPT-020 disruption recovery, OPT-026 voyage optimisation, VIS-048 turnaround milestones. The same telematics data feeds PRED-030 driver scoring, but keep that purpose strictly separate (see below).

Effort, cost & KPIs

• Path A: weeks to integrate a visibility platform with the TMS/ERP. Carrier onboarding is the long pole. Pricing is usually per tracked shipment or subscription.
• Path B: 2–4 months for a first production model on your own history. API costs scale with routing calls, so cache and reuse matrices.
• Path C: 3–6 months incl. routing engine and streaming. Ops effort covers map updates and model retraining.
• Path D: quarters, plus a dedicated ML team. Only for platforms where ETA accuracy is a core product KPI.
• KPIs: MAE/median absolute error at fixed horizons (e.g. 24 h, 4 h, 1 h before arrival), share within ±X minutes, interval coverage (is P90 really 90%?), late-alert precision/recall and lead time, status-call volume (WISMO), dock idle time, detention/demurrage cost, and the share of promised windows met.

People & change

Involve management for scope and the customer promise, then the logistics or dispatch lead who owns the process. Dispatchers and drivers are the end users and should be consulted before the pilot, since their data feeds the model. IT integrates TMS and telematics; suppliers (carriers, subcontractors) must agree to share status data. The DPO is needed because driver positions are personal data.

Works council: depends, but often yes. Vehicle positions and delivery times of identifiable drivers are suited to monitor behaviour and performance, so §87(1) no. 6 BetrVG applies under BAG case law. Work towards a works agreement that limits use to ETA, bars individual performance ranking and sets short retention (GUIDE-004). Inform the council early under §90(1) no. 3.

Data protection: DPIA check under Art. 35 GDPR if driver tracking is systematic; AVV with telematics and API providers (GUIDE-005).

AI literacy: support dispatchers with a short training on prediction intervals (GUIDE-006). Start with one depot or lane, run ETAs in parallel with manual estimates for several weeks, and keep humans in control: dispatchers can override ETAs and decide on re-routing. Typical concern: "this is driver surveillance". Address it with transparent purpose limits and aggregation (GUIDE-008).

Risks, regulation & compliance

• EU AI Act: typically minimal risk. ETA prediction is not an Annex III use case, and Art. 4 AI literacy applies. It becomes high-risk if the same system is used to monitor and evaluate the performance and behaviour of drivers or couriers, or to allocate their tasks based on behaviour (Annex III point 4(b)). Keep ETA and driver performance evaluation separate by design [16]. Customer-facing chat or notification bots fall under Art. 50 transparency.
• GDPR: vehicle positions linked to a driver are personal data, and so are recipient addresses and in-app locations of consumers. Requirements: purpose limitation (ETA/logistics, not surveillance), data minimisation (aggregate history, short retention for raw traces), pseudonymisation in training data, DPIA for systematic location tracking of employees, and a DPA with visibility vendors. Carriers share data with shippers. Clarify the controller/processor roles.
• Employment law (DE): telematics and tracking of employees is subject to works-council co-determination (§87(1) No. 6 BetrVG). Conclude a works agreement that excludes performance monitoring from ETA data.
• Sector rules: EU driving/rest times (Reg. 561/2006) as constraints, eFTI for electronic transport data [15], and consumer-law delivery promises (communicated delivery dates must be realistic).
• Risks & mitigations: overconfident promises lead to complaints, so publish conservative quantiles. Silent drift after network/carrier changes calls for monitoring of coverage and error per lane. Spoofed or missing GPS data needs plausibility checks and fallbacks to the plan.

Getting started

1. Collect 6–12 months of planned vs. actual arrival times per stop/shipment and measure today's accuracy at fixed horizons. This is your baseline.
2. Decide the perspective: a shipper with many carriers → Path A (RTTV platform); own fleet or delivery platform → Path B/C.
3. Start with a traffic-aware routing baseline plus a GBDT residual model with quantile outputs, and evaluate per lane and site.
4. Wire one decision to the ETA (dock rescheduling, customer window, or exception alert) and measure its business KPI, not only MAE.
5. Agree retention and purpose limits for location data with the DPO and works council before rollout.

Sources

1. Google DeepMind — Traffic prediction with advanced Graph Neural Networks — https://deepmind.google/discover/blog/traffic-prediction-with-advanced-graph-neural-networks/
2. Derrow-Pinion et al. — ETA Prediction with Graph Neural Networks in Google Maps (CIKM 2021) — https://arxiv.org/abs/2108.11482
3. Uber Engineering — DeepETA: How Uber Predicts Arrival Times Using Deep Learning — https://www.uber.com/blog/deepeta-how-uber-predicts-arrival-times/
4. Hu et al. — DeeprETA: An ETA Post-processing System at Scale — https://arxiv.org/abs/2206.02127
5. Shippeo — Real-time transportation visibility & predictive ETA — https://www.shippeo.com/
6. project44 — Movement Decision Intelligence Platform — https://www.project44.com/
7. Transporeon (Trimble) — Transport management & visibility platform — https://www.transporeon.com/en
8. FourKites — Supply chain visibility, ML-powered ETAs and AI agents — https://www.fourkites.ai/
9. Portcast — Predictive ocean visibility — https://www.portcast.io/
10. Google Maps Platform — Routes API overview — https://developers.google.com/maps/documentation/routes/overview
11. Valhalla open-source routing engine — https://github.com/valhalla/valhalla
12. OSRM backend — https://github.com/Project-OSRM/osrm-backend
13. Wu et al. — LaDe: The First Comprehensive Last-mile Delivery Dataset from Industry — https://arxiv.org/abs/2306.10675
14. Cainiao-AI — LaDe dataset & leaderboards (route prediction, ETA) — https://huggingface.co/datasets/Cainiao-AI/LaDe
15. European Commission — eFTI Regulation (EU) 2020/1056 — https://transport.ec.europa.eu/transport-themes/logistics-and-multimodal-transport/efti-regulation_en
16. Regulation (EU) 2024/1689 (AI Act), Annex III — https://eur-lex.europa.eu/eli/reg/2024/1689/oj