At a glance
Absolute count of DPDLocal parcels that delivered after their promised date in the trailing 7 days. The numerator-side counter on the OTD relationship; rises before the OTD percentage moves on a growing merchant. Used as the daily-triage queue length for CS and operations.
| What it counts | COUNT(consignments WHERE actualDeliveryDate > expectedDeliveryDate) over the 7-day window. Each consignment is its own row, not aggregated to order level. A multi-parcel order with two late parcels increments by two. |
| Service code scope | All DPDLocal services pooled (NextDay, Predict, Sunday, EU, Highlands). |
| Returns / RTO | Excluded. RTOs never deliver to the original address, so they cannot be “late”. They live in the Returned to Sender card. |
| Failed deliveries (RUS, refused, address invalid) | Excluded once the consignment terminates as RETURNED_TO_SENDER or FAILED. Counted as late while the consignment is still in attempted-delivery state past the promise date. |
| In-flight (still in transit, past promise) | NOT counted in this card, even when the parcel is materially late. This card waits for actualDeliveryDate. To track in-flight overdue, use Parcels In Flight cross-referenced with expectedDeliveryDate < today. |
| CS workload signal | Each late parcel typically generates 1.2 to 1.8 inbound CS contacts (where-is-my-order tickets, chat, email). The count here is a useful predictor of next-week CS staffing demand. |
| Time window | 7D (rolling 7 days). Shorter than OTD’s 30D window because this is a daily-triage queue, not a trend metric. |
| Alert trigger | >5% of total. Pairs with Shipments for the percentage interpretation. |
| Roles | owner, operations |
Calculation
Calculated automatically from your DPDLocal data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
A UK-based health-supplements brand on Shopify, ~700 DPDLocal parcels per week mostly on NextDay. Reading taken at 09:00 GMT on 12 Mar 26 for the trailing 7 days (5 Mar to 11 Mar 26).| Day | Total delivered | Late | % of day |
|---|---|---|---|
| Wed 5 Mar | 142 | 4 | 2.8% |
| Thu 6 Mar | 138 | 5 | 3.6% |
| Fri 7 Mar | 165 | 8 | 4.8% |
| Mon 10 Mar | 110 | 3 | 2.7% |
| Tue 11 Mar | 145 | 6 | 4.1% |
| 7-day (this card) | 700 | 26 | 3.7% |
>5% of total is not tripped (3.7%). Three things to notice:
- Friday is the bad day. 8 late on the highest-volume day suggests the Thursday-evening collection or the Friday-morning sortation is the bottleneck. Pair with Failed Pickup Rate to confirm.
- The CS queue has 26 late parcels to chase. At ~1.5 contacts each, that is 30 to 45 CS tickets this week directly traceable to this list. Pre-emptive outreach (auto-email “we know your parcel is late, here is the new ETA”) cuts inbound by 40 to 60%.
- 3.7% under a 5% alert threshold is healthy but worth watching. A persistent climb from 1.5% to 3.7% over four weeks would precede an OTD warn at the 30-day window. Treat the trajectory of this card as the early-warning signal.
Sibling cards merchants should reference together
Late Shipments is a daily operational queue. Pair with these to triage and quantify impact:| Card | Why pair it with Late Shipments | What the combination tells you |
|---|---|---|
| On-Time Delivery Rate | The percentage view (this is the count). | A rising count with flat percentage means the business is growing; a rising count with a falling percentage means a real network problem. |
| Late Shipments by Route | Splits by UK postcode area. | Identifies which regions are concentrating the misses. |
| Exception Reasons | Splits by reason (recipient-not-home, address error, weather, depot delay). | Tells CS and operations whether the fix is internal (address quality, picking) or carrier-side. |
| Late-Delivery Revenue at Risk | Cross-channel money number. | Quantifies refund / chargeback exposure on the late list. |
| Open Claims Without Jira Ticket | Coverage check. | Surfaces late parcels with no CS ticket, the silent customer-trust gap. |
| Cross-connector: customer NPS / Klaviyo post-purchase survey | Downstream sentiment lag. | Late parcels depress 7-day NPS by 5 to 12 points within the affected cohort. |
Reconciling against the vendor’s own dashboard
Where to look in DPDLocal’s own dashboard: MyDPD Business Portal → Tracking → Filter “Late deliveries”, Last 7 days. Each row showsexpectedDeliveryDate, actualDeliveryDate, and the gap. The portal also exposes a downloadable CSV per filter.
Why our number may legitimately differ from MyDPD:
| Reason | Direction | Why |
|---|---|---|
| Time zone | Edge cases | MyDPD reports in UK local time; the card uses UTC. A parcel delivered at 23:30 UTC on a promised-by-23:59 GMT day is on time; some card boundary cases may flip. |
| Driver-PDA scan lag | Ours lower for “today” | Drivers sync PDAs at depot; some scans take 4 to 8 hours to surface in the API. Today’s count may underread. |
| Failed-then-redelivered classification | Ours typically higher | Some MyDPD reports class a parcel that failed-then-redelivered as “delivered on the redelivery attempt”. The card scores against the original expectedDeliveryDate; if redelivery happened a day late, it counts late. |
| DPDLocal vs mainline DPD scope | Ours scoped | The portal shows both contracts under one login; the card scopes to DPDLocal consignments only. |
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
| Customer NPS / post-purchase surveys | Downstream sentiment, lagged 7 to 14 days. | Survey response bias, sample size. |
shopify.refund_rate | Late shipments precede refund-rate climbs by 7 to 14 days. | Other refund drivers (quality, fit, sizing) confound the relationship over longer windows. |
Known limitations / merchant FAQs
Why does the count look different from the OTD percentage? This card is a count; OTD is a rate. On a growing merchant, the count rises naturally even as the rate stays flat (more total parcels means more late ones at the same percentage). Use this card for daily triage and CS staffing; use OTD Rate for trend and SLA conversations. A late parcel that eventually delivers, does it stay in this card forever? No, only while it falls within the rolling 7-day window starting from the day it actually delivered. After the window rolls past, it leaves the count. The card always reads “parcels that delivered late in the last 7 days”. My count spiked but OTD did not. What gives? Two usual reasons. (1) You shipped more parcels. A 30% volume increase week-over-week with constant OTD lifts the count by 30%. (2) Window edge effect. A small late-Friday cluster from last week may have rolled out of the window today; whichever bucket has more late deliveries dominates the snapshot. Why is the count on the count card lower than the absolute number of late tracking events I see? The card counts consignments that have actually delivered (actualDeliveryDate IS NOT NULL) and were past their promise. In-flight overdue parcels are not yet counted; they are held in Parcels In Flight. When they deliver, they enter this card.
Is a parcel that the customer refused counted as late?
No. Customer refusal terminates the consignment as FAILED or REFUSED; it never reaches DELIVERED. It does not count here. It does count in Failed Deliveries.
Should I send pre-emptive “parcel late” emails to the customers on this list?
Almost always yes. Pre-emptive outreach cuts inbound CS contacts by 40 to 60% and lifts NPS even on the late cohort by 5 to 8 points (customers who feel kept-informed forgive lateness more readily). Klaviyo or Dotdigital can drive this; the trigger is a Vortex IQ webhook on this card.
The Friday spike repeats every week. Why?
Two structural patterns common to UK shippers. (1) Thursday-evening collection volume vs Friday capacity. If your inbound volume to DPDLocal peaks on Thursday but DPDLocal’s Friday-morning sortation is at capacity from other merchants, your parcels miss the cutoff. Negotiate an earlier collection slot. (2) Predict-window misses on Friday afternoons. Drivers running behind on Friday afternoons miss 30-min slots; pair with Predict Slot Accuracy to confirm.