General
Why Your Delivery Promise Breaks Before the Van Leaves: A Delivery Experience Optimization Framework
Aug 25, 2026
12 mins read
Key Takeaways
- A missed delivery is usually the last event in a failure that started hours earlier, at a decision nobody connected to the promise.
- Five pre-dispatch decisions determine whether a promise is achievable: the capacity check at order capture, release timing, load build, departure adherence, and route feasibility at plan time.
- CX owns the promise and has visibility into none of those five. That is why Delivery Experience Optimization stalls when it is run as a communications programme.
- The diagnostic is the promise-to-plan gap: at each stage, compare what the promise assumed against what the operation committed. The stage where they diverge is your actual problem.
- Reliability is now worth more than speed to customers, which makes promise accuracy the cheaper investment.
The promise breaks upstream
A customer receives a delivery outside the window they were given. The post-mortem looks at the route, the driver, and the traffic.
In most cases the route was already infeasible when the driver collected it. The promise was made at checkout against a lead-time table. Release happened late because the wave was scheduled around labour rather than around collection. The load was built without reference to the sequence it would be delivered in. The vehicle left the dock forty minutes after its slot. By the time a driver is moving, the outcome is largely determined, and everything that follows is recovery.
This matters for how the problem is owned. Delivery Experience Optimization is usually run from marketing or CX, which owns the promise, the notification, and the tracking page. None of the five decisions above sits in that function, and none of them is visible from it. So the team accountable for the outcome is working on the last link in a five-link chain.
The customer expectation makes this worth solving rather than managing. McKinsey found that speed fell from consumers’ number one delivery priority in 2022 to fifth by 2024, displaced by reliability and predictability, with around 90 percent of consumers willing to wait two to three days when delivery is free and arrives within the stated window. Customers are not asking to be served faster. They are asking to be told accurately, which is a promise-accuracy problem rather than a transit-time problem.
Also Read: Stop Routing Bad Promises: Why Last-Mile Efficiency Actually Starts at the E-Commerce Checkout
The five decisions that determine feasibility
1. The capacity check at order capture
The moment the promise is made. If the date shown to the customer comes from a static lead-time table rather than from available capacity and serviceability on that lane that day, the promise is a guess with a commitment attached.
This is the cheapest failure to prevent and the most expensive to inherit, because every downstream stage is then working to satisfy a commitment the network never had room for. Capacity-aware promising sometimes means showing a later date, which is a commercial decision worth making deliberately rather than discovering.
2. Release timing
When orders are released to the floor determines whether they can be picked, staged, and loaded in time for the collection they were promised against.
Most operations release on a wave schedule built around labour availability. That is reasonable and it is optimised for a different objective than the promise. A wave that clears by 14:00 supports a 15:00 collection; the same wave clearing at 15:30 has broken every promise in it before anyone touched a vehicle.
The failure mode here is well documented. A global FMCG leader operating across ten countries had scheduling cycles running long enough that picking stalled at the warehouse waiting on plans, with tight SLAs leaving no slack for error. Autonomous planning collapsed a three-hour manual cycle to five minutes, which removed the bottleneck rather than working around it, and next-day delivery performance improved 25 percent.
3. Load build
What goes on which vehicle, in what order. A load assembled by product type or pick sequence rather than by delivery sequence forces the driver to unload and reload at stops, which consumes the service time the plan allocated to delivering.
This is invisible in every metric CX sees. It surfaces as a driver running late from stop six onward, which looks like a routing problem and is a loading problem.
4. Departure adherence
The gap between the planned departure and the actual one, which is inherited in full by every stop on the route.
Dock congestion, late loads, and paperwork all contribute, and the cost compounds because a late departure into a fixed window compresses the time available for everything after it. ATRI found drivers were detained at 39.3 percent of all stops in 2023, losing 117 to 209 hours per year depending on sector, at a cost of 3.6 billion dollars in direct expenses and 11.5 billion in lost productivity. Facility dwell is the same phenomenon measured at the other end of the journey.
5. Route feasibility at plan time
Whether the plan the driver receives can actually be completed inside the promised windows, given realistic service times, access conditions, and the driver’s remaining hours.
Plans built on flat service-time assumptions are systematically optimistic in dense urban work, where the time between arriving at a location and completing the delivery is the dominant variable. A plan that assumes three minutes per stop and encounters eight will miss from the middle of the route onward regardless of how well it was sequenced.
Why CX cannot see any of it
Each of those five decisions is made in a different system by a different team against a different objective.
Order capture optimises conversion. Release optimises labour utilisation. Load build optimises loading speed. Departure optimises dock throughput. Route planning optimises cost per stop. Every one of those objectives is legitimate, none of them is promise accuracy, and no single view shows the promise degrading across them.
So the CX team receives the outcome and the tools to communicate about it. That is why notification programmes deliver less than expected: they improve how a broken promise is handled without changing how often promises break.
The cost of that is measurable on the customer side. Gartner’s customer effort research found 96 percent of customers who have a high-effort service experience become disloyal, against 9 percent of those with a low-effort experience, and that effort predicts loyalty roughly 40 percent more accurately than satisfaction. And PwC research indicates 42 percent of consumers cite delivery reliability as a top factor in brand choice, with approximately 32 percent saying one bad experience would stop them buying from a brand they otherwise liked.
Also Read: The Delivery Experience Trust Gap: Why US Retailers Can’t Compete on Speed Alone in 2026
The promise-to-plan gap diagnostic
One analysis locates the break. At each of the five stages, compare what the promise assumed against what the operation actually committed.
| Stage | What the promise assumed | What to measure | The break looks like |
|---|---|---|---|
| Order capture | Capacity existed on that lane that day | Share of promises made without a capacity check | Promise dates cluster on days the network was already full |
| Release | Orders would be ready for the planned collection | Wave completion time against planned collection time | Waves clearing after the collection slot |
| Load build | Load matched delivery sequence | Share of loads built to delivery sequence | Driver-reported reload events mid-route |
| Departure | Vehicle left on its slot | Actual against planned departure, by depot | A consistent depot-level delay inherited by every route |
| Route plan | Stops completable in promised windows with real service times | Planned against actual service time per stop type | Misses beginning consistently from the same position in the sequence |
That last column is the most useful diagnostic signal in the table. If misses start from roughly the same stop number across many routes, the cause is upstream and cumulative, not situational. If they are scattered, the cause is local.
Run this once and the conversation changes, because the finding is a stage rather than a department.
What changes when promise is an execution capability
Three shifts, in order of leverage.
The promise is computed rather than looked up. Capacity and serviceability checked at the moment of commitment, so the network is never asked to satisfy something it had no room for.
Feasibility is re-evaluated as the chain progresses. A late wave or a late departure updates the promise rather than silently invalidating it, which means the customer hears about a change while it is still information rather than a failure.
Exceptions trigger action, not alerts. Where a promise can no longer hold, the system re-sequences, reassigns, or reissues the commitment with a choice attached. Detection alone changes nothing, and this is where most stacks stop: Gartner found that while 95 percent of supply chains must react quickly to change, only 7 percent can execute decisions in real time.
Also Read: The Hidden Cost of Failed ETA Promises: How AI Routing Breaks the 95% Accuracy Barrier
What to measure
Four measures, none of which is a survey.
Promise accuracy, the share of orders delivered inside the window shown at checkout, reported by metro and by carrier rather than blended.
Promise-to-plan gap by stage, per the table above, which is the diagnostic rather than the outcome.
Proactive rate, the share of at-risk deliveries where the customer was told before they enquired.
Repeat purchase rate segmented by whether the previous order arrived on promise, which is the measure that connects this work to revenue rather than to cost avoidance.
Where Locus fits
Locus, the world’s first Decision-Intelligent, Agentic TMS, sits across the stages where the promise is actually determined rather than only at the point it is communicated.
Within DiSCO, the Capacity agent evaluates available capacity so the commitment at order capture reflects the network rather than a table, the Hub agent manages facility readiness and the dispatch handover, the Dispatch agent plans and re-sequences against 250+ real-world constraints including realistic service times, and the Customer agent issues the revised commitment when feasibility changes. Because the notification is generated from the dispatch decision rather than from a status field, a revised time reflects what the system just decided.
Locus has been recognized by Gartner for seven consecutive years, featured in the 2026 Hype Cycle for Supply Chain Execution and Logistics Technologies, named a Leader in TMS by QKS Group (SPARK Matrix), and ranked #1 in Route Planning on G2’s 2026 Best Software Awards. In October 2025, Ingka Investments, the investment arm of Ingka Group, the world’s largest IKEA retailer, acquired Locus. Locus continues to operate independently.
The clearest evidence sits at stage one. A leading ASEAN apparel retailer could not compute a delivery date across its carrier mix, so the storefront showed only a rough lead time. That single gap drove hundreds of thousands of delivery and returns complaints in a single half-year. With a network-aware delivery date computed at checkout, labels and shipments created at packing, and every shipment tracked to its promise on the retailer’s own site, WISMO and returns queries fell more than 40 percent while delivery SLA held above 99 percent.
Note what changed there. Not the carriers, not the transit times, and not the notification copy. The promise became computed rather than assumed, and the complaint volume followed.
Also Read: The Reliability Revolution: Why 20% of US Consumers Now Prioritize Predictable Delivery Over Speed
The analysis to run first
Take a month of missed promises and record the stop number at which each route first fell behind.
If the distribution clusters around a similar position across many routes, the cause is upstream and cumulative, and the five-stage table tells you where to look. If it is flat, the cause is local and the answer is service-time modelling rather than process redesign.
Either result is more actionable than a month of CSAT, and it takes an afternoon.
Learn more, visit locus.sh
FAQs
Why do delivery promises fail?
Usually upstream of the delivery. Five pre-dispatch decisions determine feasibility: whether capacity was checked when the promise was made, whether release timing supports the planned collection, whether the load was built to delivery sequence, whether the vehicle departed on its slot, and whether the route plan used realistic service times. By the time a driver is moving, the outcome is largely set and everything after is recovery.
Is delivery promise accuracy a CX problem or an operations problem?
An execution problem owned by CX. Each of the five decisions that determine feasibility sits in a different system with a different objective: conversion at capture, labour utilisation at release, loading speed at load build, dock throughput at departure, cost per stop at planning. None optimises for promise accuracy, and none is visible from the CX function that owns the outcome.
What is capacity-aware promising?
Computing the delivery date at the moment of commitment against real available capacity and carrier serviceability, rather than applying a static lead-time table. It sometimes means showing a later date, which is a deliberate commercial choice, and it prevents the situation where every downstream stage is working to satisfy a promise the network never had room for.
How do you diagnose where a delivery promise breaks?
Compare what the promise assumed against what the operation committed, at each of the five stages. The most useful single signal is the stop number at which routes first fall behind: if misses begin from roughly the same position across many routes, the cause is upstream and cumulative, and if the distribution is flat, the cause is local and points to service-time modelling.
Do better notifications reduce missed deliveries?
No. They improve how a broken promise is handled, which is valuable, and they do not change how often promises break. That is why notification programmes frequently deliver less than expected: the intervention sits at the last link of a five-link chain, and the failures originate earlier.
Should retailers promise faster or more accurately?
More accurately, on current evidence. McKinsey found speed fell from consumers’ first delivery priority in 2022 to fifth by 2024, displaced by reliability and predictability, with around 90 percent willing to wait two to three days when delivery is free and arrives within the stated window. Promise accuracy is also generally cheaper to improve than transit time.
Ishan, a knowledge navigator at heart, has more than a decade crafting content strategies for B2B tech, with a strong focus on logistics SaaS. He blends AI with human creativity to turn complex ideas into compelling narratives.
Related Tags:
General
10 Best Last Mile Logistics Software Platforms for Enterprise Operations in 2026
Compare the 10 leading last mile logistics software platforms for enterprise operations with AI dispatch, route optimization, and orchestration features.
Read more
General
Driver Management and Retention in Europe: Why Route Design Causes More Churn Than Pay Does in 2026
European driver management treats churn as a pay problem. Route design causes more of it. The five mechanisms, what to measure, and how fatigue-aware allocation improves retention.
Read moreInsights Worth Your Time
Why Your Delivery Promise Breaks Before the Van Leaves: A Delivery Experience Optimization Framework