Delivery promises do more than set a shipping expectation. They influence conversion before purchase, generate customer contacts after purchase, and determine whether a shopper trusts the brand enough to return. Yet many ecommerce reports reduce the subject to average delivery time. An average is useful for capacity planning, but it can hide the promises that were missed, the orders that never received a reliable date, and the customer groups most affected by exceptions.
The better operating question is: “Did we keep the promise we showed at the moment this customer decided to buy?” That requires a measurement model that preserves the promise, the order state, and the eventual outcome.
Table of Contents
- Keyword and intent
- Why averages hide delivery risk
- Delivery-promise scorecard
- Measure the promise at order time
- Segmenting exceptions that matter
- 30-day analysis plan
- Checklist
Keyword and intent
- Primary keyword: ecommerce delivery promise analytics
- Secondary keywords: shipping performance statistics ecommerce, delivery accuracy KPI, post-purchase analytics
- Search intent: Commercial-informational
Why averages hide delivery risk
Imagine two delivery services. Both show an average of three days. One completes almost every order inside a two-to-four-day promise. The other delivers half in one day and leaves a meaningful minority waiting nine days. The average is identical; the customer experience is not.
Ecommerce teams should therefore separate speed from reliability. Speed asks how long a delivery took. Reliability asks whether the promise shown, confirmed, and communicated was met. Confidence asks whether the customer had enough information to understand an exception before it became a complaint.
| Metric | What it reveals | What it can hide if used alone |
|---|---|---|
| Average delivery days | typical end-to-end elapsed time | long-tail delays and broken promises |
| On-time-to-promise rate | percentage meeting displayed commitment | whether the promise itself was realistic |
| Dispatch-within-SLA rate | warehouse readiness and cut-off control | carrier performance after handover |
| First tracking-event latency | how quickly customers receive reassurance | actual final delivery quality |
| Delivery-related contact rate | friction customers felt strongly enough to ask for help | silent dissatisfaction or no-contact cohorts |
| Refund or reship rate | cost of delivery failure | root cause and customer expectation gap |
Delivery-promise scorecard
Start with a definition that does not change after the order is placed. Capture the exact promise window or service label presented at checkout, the relevant fulfilment cut-off, and the destination rules. If an order is later split, back-ordered, edited, or upgraded, record that as a new operational state rather than overwriting the original evidence.
| Stage | Key timestamp or field | Owner | Question to answer |
|---|---|---|---|
| Checkout | displayed promise and selected service | storefront / platform | what did the customer agree to? |
| Order acceptance | fraud, stock, and payment state | operations | was the order ready to flow? |
| Dispatch | carrier handover timestamp | warehouse | did we meet our internal SLA? |
| Carrier scan | first and subsequent tracking events | carrier / CX | did the parcel enter a visible journey? |
| Delivery | delivered, attempted, collection, or exception | carrier | did the commitment hold? |
| Resolution | refund, reship, goodwill, or contact | CX / finance | what did the failure cost? |
The most valuable table in a weekly review is often an exception table, not a headline chart. It identifies a combination such as “remote postcode + carrier service B + Friday cut-off + oversized item” that a blended average could never expose.
Measure the promise at order time
Promise accuracy cannot be reconstructed reliably from today’s product page. Delivery messaging changes with inventory, season, carrier capacity, destination, basket composition, and cut-off time. Store what was shown when the order was made.
| Field | Why preserve it | Example use |
|---|---|---|
| Promise start and end | supports on-time calculation | distinguish a missed latest date from an early delivery |
| Service selected | explains customer expectation | compare express and standard reliability |
| Cut-off context | identifies timing risk | find orders accepted close to a missed cut-off |
| Inventory source | connects fulfilment path to outcome | compare warehouse and supplier-fulfilled orders |
| Destination group | reveals regional variation | separate domestic, remote, and cross-border performance |
| Exception reason | creates a fixable taxonomy | distinguish address, stock, carrier, and customer causes |
Be careful with the word “delivered.” A carrier scan may say delivered while the customer reports a problem; an attempted delivery may be operationally complete but commercially unsuccessful. Build a consistent resolution policy with customer-service and finance owners so reporting reflects the real customer outcome.
Related reading: ecommerce analytics statistics for customer contact drivers, delivery exceptions, and revenue protection and ecommerce analytics statistics for profitability by fulfilment speed, shipping cost, and delivery promise.
Segmenting exceptions that matter
Do not segment every possible field on day one. Start where a change is plausible: carrier service, fulfilment node, product class, destination group, order time, and customer contact reason. Each segment needs enough volume to be meaningful and an owner who can act.
| Segment | Useful hypothesis | Potential action |
|---|---|---|
| Carrier service | one service misses promises after handover | adjust allocation or customer messaging |
| Fulfilment node | a location dispatches late on peak days | change cut-offs, staffing, or routing |
| Basket type | bulky or multi-item baskets produce exceptions | revise promise rules and packaging flow |
| Geography | remote areas get generic promises that do not fit | create destination-specific estimates |
| Acquisition source | promotional traffic has different delivery expectations | align landing-page and checkout messaging |
Use customer contacts as diagnostic evidence, not a standalone quality score. A low contact rate can reflect a good experience, but it can also reflect customers who have given up or cannot find an easy help path. Read contact trends beside on-time rate, reships, refund requests, review themes, and repeat purchase behaviour.
30-day analysis plan
Week 1: define the order-time promise
Audit checkout and confirmation messaging for priority markets. Identify where the promise is generated and whether it is stored against the order.
Week 2: join operational evidence
Bring together order, warehouse, carrier, contact, refund, and reship records at a documented grain. Preserve timestamps and do not overwrite exception states.
Week 3: identify actionable variance
Review on-time-to-promise, dispatch SLA, first-scan latency, and contact rate by the five most useful segments. Validate surprising patterns with operations before publishing them.
Week 4: change one promise or process
Pilot a realistic messaging or routing change for a defined segment. Monitor customer outcome, not only the carrier’s average delivery time.
The UK Competition and Markets Authority’s guidance on online sales is useful background for fair customer communication. Operationally, the most durable approach is simple: say what you can keep, record what you said, and investigate quickly when reality differs.
Checklist
| Check | Pass condition |
|---|---|
| Order-time record | displayed promise and service are stored with the order |
| Reliability metric | on-time-to-promise is separate from average delivery time |
| Operational trace | dispatch, carrier, delivery, and resolution states are joinable |
| Exception taxonomy | causes are defined well enough to support action |
| Customer view | contacts and resolutions are included beside carrier events |
| Governance | promise changes have storefront, operations, and CX ownership |
Delivery analytics earns its place when it protects the promise customers actually made their decision on. A more truthful promise and a faster exception response often create more value than a superficially faster average.
