At a glance
Count of store orders whose promised dispatch deadline came and went without a PostNord label being printed and the parcel handed to the carrier, measured over the trailing 7 days against the prior 7. This is a despatch-side metric, not a delivery one: it catches orders stuck on the warehouse floor before PostNord ever sees them. Every breached order is a customer who paid for a cut-off they were promised at checkout (for example “order by 14:00 for same-day despatch”) and did not get.
Calculation
Calculated automatically from your PostNord and store-order 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, around 2,350 orders per week, Shopify front-end, single Gothenburg warehouse, PostNord MyPack across SE / NO / DK / FI. Checkout promise: “Order by 14:00 CET on a working day and we despatch the same day.” Reading taken at 09:00 CET on 18 Mar 26 for the trailing 7 days (11 Mar 26 to 17 Mar 26), compared against 04 Mar 26 to 10 Mar 26.
The card reads 18 breached orders, up from 3 the week before. The alert at
>0 is tripped (it is always tripped when any order breaches). Five things to notice:
- The week-on-week jump is the story, not the absolute. 3 breaches the prior week is the normal floor (a stray late pick, a printer jam). 18 is a six-fold rise and clusters in two cohorts: cross-border (8) and MyPack Home SE (9). When a zero-tolerance card jumps like this, look for a single root cause, not 18 separate ones.
- The cross-border 8 are the customs-paperwork bottleneck. Norway is outside the EU customs union, so cross-border MyPack needs a complete CN23 before the label can be booked. If the fulfilment integration started emitting incomplete customs data on 14 Mar 26, those orders cannot get a valid PostNord label and sit past the 14:00 cut-off. Cross-reference Exception Rate for a matching
CUSTOMS_HELDrise. - The MyPack Home SE 9 are a floor-time problem, not a carrier one. PostNord never saw these orders, so this is a pick-pack-print issue upstream of the carrier: a staffing gap on the 14 Mar afternoon shift, or a Shopify-to-warehouse webhook delay that hid orders from the pick queue. Check the despatch timestamps: if they all cluster after 13:00 on one day, it is a shift-capacity problem.
- Each breached order is a refund-and-goodwill liability. A customer who paid for same-day despatch and did not get it is a candidate for a shipping refund (SEK 49 to 79 here) plus a where-is-my-order ticket. 18 breaches is roughly SEK 1,100 of shipping-fee exposure plus around 2.5 staff-hours of customer-service time, before any downstream late-delivery cost.
- This card is the leading edge of revenue-at-risk. A dispatch miss today is a late delivery in 1 to 3 days and a possible return or refund in 7 to 14. Acting now (clear the floor backlog, fix the CN23 feed) is far cheaper than absorbing the refund and the review damage later. That is why it sits in the Cross-Platform: Revenue at Risk class.
Sibling cards merchants should reference together
Dispatch SLA breach is the earliest revenue-at-risk signal in the despatch chain. Pair it with these to find the cause and size the downstream impact:Reconciling against the vendor’s own dashboard
Where to look in PostNord’s own portal: This card is a join, so no single PostNord screen shows it. Reconcile in two halves. For the despatch-deadline half, use your store admin (Shopify Orders filtered by created date and fulfilment status, or the BigCommerce / Adobe equivalent) against your own published cut-off rule. For the carrier-handoff half, use the PostNord Business Portal → Shipments list and Reports → Tracking Events, and check each order’s first depot scan time against its booking time. The closest like-for-like check is: take the breached order IDs from the card, find each in the PostNord portal, and confirm the firstIN_TRANSIT scan timestamp is after your published cut-off (or absent entirely).
Why our number may legitimately differ from a manual count:
Cross-connector reconciliation:
Known limitations / merchant FAQs
Why does this fire on a single order when my other cards have percentage thresholds? Because the unit here is a broken paid-for promise, not a network-health average. A customer who bought a “despatch today” cut-off and did not get it has a concrete grievance regardless of how small the percentage is. The card is deliberately zero-tolerance so the operations lead sees the first breach and can intervene before it becomes a cluster. If you genuinely want to suppress single strays, raise the threshold in Settings → Alerts → PostNord Dispatch SLA, but most merchants keep it at zero. An order shows breached but I know it was handed to PostNord on time. Why? Ingestion lag. PostNord’s first depot scan can land 30 minutes to several hours after the physical handoff, especially on the late-afternoon collection that follows your cut-off. The card waits for a movement scan, not a printed label, so a parcel handed off at 13:55 whose first scan ingests at 16:10 reads as breached in between. It self-corrects when the scan arrives. If a parcel is still breached 24 hours later, it was probably never actually collected: check Shipments with Tracking-Event Gap. How is the dispatch deadline set, and what about weekends and holidays? The deadline is your own published cut-off, configured per warehouse and per service in the connector manifest. The working-day clock skips weekends and the public-holiday calendar for the destination country, so a Friday-15:00 order on a same-day-by-14:00 rule is due the following Monday, not Saturday. Norway’s 17 May, Sweden’s Midsummer, and the Nordic Christmas cluster all shift the clock. If your manifest cut-off is wrong, the card will be wrong: keep it in sync with your checkout copy. Does a cross-border customs hold count as my fault? The card counts it as a breach because the customer experienced a missed despatch, but the root cause is usually upstream of PostNord. Norway and Iceland sit outside the EU customs union, so cross-border MyPack needs a complete CN23 (HS code, value, recipient ID) before PostNord will book the label. Incomplete customs data blocks the label, the cut-off passes, and the order breaches. Fix it in the fulfilment integration that generates the CN23, not at the carrier. A cross-border breach spike with a matchingCUSTOMS_HELD rise on Exception Rate confirms this pattern.
Multi-parcel orders: how are they counted?
One order counts once. If a three-parcel order has two parcels dispatched on time and one stranded, the order is breached (the customer’s order is not complete). To see the stranded parcel specifically, use the parcel-level Shipments with Tracking-Event Gap card.
The count spiked but my warehouse says nothing changed. Where do I look?
Three usual causes, in order: (1) a label-booking outage, check Label Generation Success and API Error Rate for a matching dip; (2) a store-to-warehouse webhook delay that hid orders from the pick queue, the breaches will cluster tightly in time; (3) a cut-off-clock edge, did a public holiday compress two days of orders into one despatch window? If all three are clear, it is a genuine floor-capacity gap on a specific shift.
Why is this in the Revenue at Risk class rather than Delivery Performance?
Because it measures money the merchant has already taken against a promise not yet kept. It is the earliest point in the chain where a paid-for commitment is at risk, ahead of transit, ahead of delivery, ahead of returns. Catching it here is the cheapest possible intervention, which is exactly what a revenue-at-risk card is for.