At a glance
Absolute count of PostNord shipments delivered AFTER their service-code aim date in the trailing 7 days. The count behind OTD Rate’s percentage. A 95.7 percent OTD on 2,500 weekly parcels reads “fine”; the same OTD as 108 late deliveries reads “108 customer-service tickets in flight”. The percentage tells you about quality; the count tells you about workload.
| What it counts | COUNT(shipments WHERE delivered_at > aim_delivery_date) over the trailing 7 days. The aim_delivery_date comes from PostNord’s per-service-code aim, the delivered_at from the parcel’s delivery scan. |
| Why a count not just a rate | Customer-service workload scales with the count, not the rate. A merchant going from 1,000 to 10,000 weekly parcels at constant 96 percent OTD goes from 40 late tickets/week to 400, the team needs proportional CS capacity. The rate hides that scaling story. |
| Delivery success criterion | A delivery scan exists at the recipient’s address (POD scan for home delivery, pickup-point arrival scan for MyPack Collect). Parcels still in transit when the aim date passes are NOT counted as late on this card; they’re counted in Exception Rate until they finally deliver, at which point they shift to this card. |
| On-time threshold | Same day as the service-code aim date, in the destination country’s local timezone. PostNord publishes per-service-code aim dates; the card uses whatever PostNord returns at label-print time. |
| Service level scope | All tracked services (MyPack Home, MyPack Collect, Express, Cross-Border, International Tracked). Untracked letter-mail excluded. |
| Climate impact | Late count is climate-sensitive. A typical Nordic winter (Dec to Feb) produces 1.5 to 2.5× the summer-baseline late count even at the same shipment volume. Annotate seasonally; the alert threshold of 5 percent triggers in winter on weather-driven volatility, not on operational degradation. |
| Returns / RTO | Excluded (outbound only). Late returns are tracked separately on the Returned to Sender card. |
| Refresh cadence | Hourly. Late status is computed at scan time; a parcel scanned as delivered at 14:00 against an aim of 13:59 the same day flips to “late” within the next hour’s update. |
| Time window | 7D (rolling 7 days). The shorter window than OTD’s 30-day reflects the operational use, this card drives this-week’s CS staffing and this-week’s WISMO email volume. |
| Alert trigger | >5% of total. Equivalent to <95 percent OTD; the count framing surfaces the workload reality. |
| Roles | owner, operations |
Calculation
Calculated automatically from your PostNord data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.Worked example
The Stockholm outdoor-apparel brand. Reading taken at 09:00 CET on 14 Mar 26 for the trailing 7 days (07 Mar to 13 Mar 26).| Window | Total PostNord shipments | Late shipments | Late rate | OTD rate equivalent |
|---|---|---|---|---|
| 07 Mar to 13 Mar 26 (this card) | 2,420 | 108 | 4.5% | 95.5% |
| 14 Feb to 20 Feb 26 (snowstorm week) | 2,180 | 286 | 13.1% | 86.9% |
| 11 Jul to 17 Jul 25 (summer baseline) | 2,560 | 64 | 2.5% | 97.5% |
- 108 late deliveries this week, alert at >5% (which is 121 late at this volume) is just clear. The team can absorb this; CS capacity is sized for 80 to 130 weekly late tickets.
- The 14 Feb week was the snowstorm spike. 286 late shipments, 4× the summer baseline. This is the kind of week that breaks CS workflows: WISMO ticket volume on Day 8 to Day 10 (when customers email) is roughly equal to the late-shipment count. 286 incoming WISMO tickets in a single week against a CS team sized for 100 means tickets sit in queue for 48 to 96 hours; customer satisfaction collapses.
- The summer baseline of 64 lates per 2,560 shipments (2.5 percent late, 97.5 percent OTD) is the achievable floor. Setting alert thresholds at “summer baseline + 50 percent” gives a more useful winter alert than the constant 5 percent threshold.
- The compounding workload. Each late shipment generates approximately 1.2 customer-service tickets (some customers email twice, some don’t email at all but lodge a complaint via review or social), 0.15 refund requests, and 0.4 reorder probability decline. 108 late shipments translates to ~130 tickets, ~16 refund requests, and ~43 customers less likely to reorder, roughly £3,000 of measurable revenue impact per 100 late shipments at this brand’s AOV and contribution margin.
- The “108 lates is fine but tickets are flooding” debug case. If late count is in healthy band but CS is overwhelmed, the cause is upstream of late delivery, often Exception Rate climbing (parcels stuck in transit-not-yet-late but customers worry about them) or warehouse-fulfilment delays (parcels labelled-not-shipped). The late-shipments count is the delivered-late signal, not the full anxious-customer signal.
- Recovery shape after weather events. After the 14 Feb snowstorm week (286 lates), the next week’s count was 142 (still elevated, recovery backlog draining); the week after was 96 (back near baseline). Plan CS capacity for a 2-week tail after major weather events.
Sibling cards merchants should reference together
| Card | Why pair it with Late Shipments | What the combination tells you |
|---|---|---|
| OTD Rate | The percentage view of the same data. | Use percentage for trend, count for workload. |
| Exception Rate | Pre-late signal. | Rising exception rate predicts a rising late count at 24 to 48 hours lag. |
| Failed Deliveries | Hard-failure subset. | Late-but-eventually-delivered (this card) is recoverable; failed delivery (peer) is not. |
| First-Attempt Delivery Rate | First-attempt success. | Late count rising while first-attempt holding equals transit-time issue, not delivery-attempt issue. |
| Avg Transit (days) | Speed correlate. | Transit days creeping up predicts late count rising next week. |
| Open Claims | Downstream. | Late count this week predicts open-claim volume in 14 to 21 days. |
Cross-connector: shopify.refund_rate, bigcommerce.bc_refund_rate | Customer-impact correlate. | A 100-late spike typically drives a 0.3 to 0.8 point refund-rate uptick at 14-day lag. |
Cross-connector: shopify.support_ticket_volume | CS workload correlate. | Late count of N typically generates 1.0 to 1.4 N WISMO tickets over the following 7 days. |
Cross-connector: bring.bri_late_shipments_count | Adjacent Nordic carrier peer. | Compare carrier-mix late counts to inform carrier-portfolio decisions. |
Reconciling against the vendor’s own dashboard
Where to look in PostNord’s own portal: PostNord Business Portal → Reports → Service Performance, switch the view from “Rate” to “Count”. Filter to the trailing 7 days and outbound-only. The card’s headline count should agree with PostNord’s count to within 1 to 3 percent. Larger gaps trace to the same TZ / ingestion-lag / cross-border-attribution reasons documented on the OTD Rate card; the count and rate use the same underlying population. Why our number may legitimately differ from PostNord’s report:| Reason | Direction | Why |
|---|---|---|
| Time zone | Boundary days off | Portal uses local TZ; card uses UTC. Day-boundary parcels can shift count by a handful. |
| Tracking-event ingestion lag | Ours lower for “today” | 30-min to 4-hour lag on scan ingestion means recently-late parcels may not yet be in the count. |
| In-transit edge case | Either | A parcel scanned as delivered at 23:55 local on the aim date, against an aim ending at 23:59 local, is on-time in the local view; if our UTC conversion bumps it past midnight the card flips it to late. Matters only for late-day deliveries. |
| Cross-border last-mile attribution | Either | Cross-border consignments use destination-carrier scans; the destination-carrier’s lag is independent of PostNord’s, leading to brief count drift. |
| Excluded vs flagged | Different | The card excludes parcels still in transit past their aim date from the late count (they’re in Exception Rate); the portal sometimes shows them in both views. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
shopify.support_ticket_volume, bigcommerce.bc_support_ticket_volume | Late count drives WISMO ticket volume at 1.0× to 1.4× lag of 3 to 7 days. | Customer-side variability: some merchants get 0.5× per-late ticket rate, some 1.8×; depends on checkout-promised-date discipline. |
shopify.refund_rate | Late count of N typically drives ~0.005×N refund requests at 14-day lag. | Refund rate has many drivers; this is one input. |
bring.bri_late_shipments_count | Adjacent carrier peer. | Different populations; the comparison informs carrier-mix decisions. |
| PostNord OTD Rate | Identity: late_count = (1 − OTD_rate) × total_shipments. | The two should agree to 1 to 2 percent; larger gap is a data sync issue. |