> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # Orders with Dispatch SLA Missed, Bring > Orders with Dispatch SLA Missed for Bring stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Card class:** [Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Cross-Channel: Revenue at Risk](/nerve-centre/overview#card-classes-explained) ## At a glance > Count of ecommerce orders that did not leave your warehouse and get a first Bring scan before their promised dispatch deadline, over the trailing 7 days against the prior 7 days. This is the despatch-floor metric, not the carrier metric: it measures whether your team handed the parcel to Bring on time, before transit even begins. A single missed dispatch SLA is one customer whose checkout promise is already broken. | | | | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(orders WHERE first_bring_scan_at > dispatch_deadline OR (first_bring_scan_at IS NULL AND dispatch_deadline < now))` over the rolling 7-day window. The dispatch deadline is derived from the order's checkout promise (cut-off time plus handover lead time) per Bring product code. | | **Data source** | Store order feed (Shopify / BigCommerce / Adobe Commerce order created and fulfilment events) joined to the Bring Booking API consignment record and the first registered tracking event from the Bring Tracking API (`GET /tracking/api/v2/tracking`). The order's `created_at` and the consignment's first `OrderProcessed` / `RecipientNotified` scan bracket the dispatch window. | | **Cross-channel join** | Orders arrive from every sales surface (own store, marketplaces, wholesale). This card attributes the dispatch miss back to the order, so a marketplace order and a D2C order are scored on the same despatch clock. | | **Bring product scope** | All Bring outbound products in use: Pakke til hentested (Mypack Collect), Pakke levert hjem (home delivery), Bedriftspakke (business parcel), and Nordic export products. Each product carries its own handover cut-off. | | **In-flight handling** | Orders not yet past their dispatch deadline are excluded. Orders past deadline with no Bring scan are counted as missed (the parcel never left). Orders with a first scan stamped after the deadline are counted as missed even if they later deliver on time. | | **Time window** | `7D vsP` (rolling 7 days, compared with the previous 7 days). The vsP comparison flags whether despatch discipline is improving or slipping week on week. | | **Alert trigger** | `>0 orders breached`. This is a zero-tolerance card: any order that misses its dispatch promise is a broken checkout commitment, so the alert fires on the first breach rather than on a percentage threshold. | | **Roles** | owner, operations | ## Calculation The card works on the order, not the consignment, so it captures despatch failures that pure carrier metrics never see. For each order in the window it resolves a dispatch deadline. The deadline is the later of two clocks: the carrier handover cut-off for that Bring product (for example, Mypack Collect parcels booked before the daily 14:00 cut-off are expected on the same evening's collection), and the store's own published despatch promise at checkout ("order before 15:00 for same-day despatch"). The card then looks for the first Bring tracking event against the consignment booked for that order. If that event is stamped after the deadline, or if no event exists and the deadline has already passed, the order scores as a dispatch SLA miss. Scan timestamps come back from the Bring Tracking API in carrier-local time (Norwegian time for NO-origin shipments). The card normalises everything to UTC for storage, then renders in your configured display timezone, so the deadline comparison is always made on a single clock. Calculated automatically from your Bring and store-order data. See the At a glance summary above and the worked example below. ## Worked example A Norwegian outdoor-apparel brand based in Oslo, around 1,900 outbound orders per week, ships predominantly on Bring: roughly 70 percent Pakke til hentested (Mypack Collect), 25 percent Pakke levert hjem (home delivery), 5 percent Nordic export to SE and DK. Checkout promises "Bestill innen 15:00 for samme-dags forsendelse" (order before 15:00 for same-day despatch). The Bring collection cut-off at their warehouse is 16:00. Reading taken at 08:00 CET on 14 Apr 26 for the trailing 7 days (07 Apr 26 to 13 Apr 26). | Sales channel | Orders (7D) | Dispatched after deadline | No-scan past deadline | Total missed | | ---------------------------- | ----------- | ------------------------- | --------------------- | ------------ | | Own store (Shopify) | 1,290 | 9 | 2 | 11 | | Finn.no marketplace | 410 | 14 | 1 | 15 | | Wholesale / B2B | 200 | 5 | 0 | 5 | | **All channels (this card)** | **1,900** | **28** | **3** | **31** | The card reads **31** orders with dispatch SLA missed, up from 19 the prior week (vsP +63 percent). The alert at `>0` is tripped. Five things to notice: 1. **The marketplace channel is the hot spot.** Finn.no is 22 percent of volume but 48 percent of the misses. Marketplace orders often import on a delayed webhook and land in the despatch queue late; the picker never saw them before the 15:00 cut-off. The fix is upstream of Bring: tighten the order-import polling, not the warehouse. 2. **vsP is the signal, not the absolute.** 31 is bad, but the +63 percent week-on-week jump is what should page operations. Something changed in the last 7 days: a staffing gap, a marketplace integration lag, or a Bring collection that was missed on one day. 3. **The 3 no-scan orders are the worst category.** These parcels have no Bring event at all and the deadline has passed: the label was printed but the parcel was never collected, or never booked. Check [Label Print Failures Spike](/nerve-centre/kpi-cards/bring/label-print-failures-spike) and [Bring Tracking API Unavailable / 5xx](/nerve-centre/kpi-cards/bring/bring-tracking-api-unavailable-5xx) first; a booking that failed silently shows up here as a no-scan. 4. **This is revenue at risk, not just an ops number.** Each of the 31 customers was promised same-day despatch and did not get it. At an average order value of NOK 850, that is roughly NOK 26,000 of orders now exposed to refund requests, "where is my order" tickets, and one-star reviews. The downstream cost lands 3 to 10 days later. 5. **A missed dispatch can still deliver on time, and still counts here.** If the picker handed the parcel to Bring at 16:30 (after the 16:00 cut-off) but it caught the next collection and delivered next day anyway, the customer never noticed, but the promise was technically broken. This card is deliberately strict because it measures process discipline; pair it with [On-Time Delivery Rate](/nerve-centre/kpi-cards/bring/on-time-delivery-rate) to see which misses actually reached the customer late. ## Sibling cards merchants should reference together Dispatch SLA miss is the earliest despatch-floor warning. Pair it with these to trace cause and downstream cost: | Card | Why pair it with Dispatch SLA Missed | What the combination tells you | | ---------------------------------------------------------------------------------------------------------- | ------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | [On-Time Delivery Rate](/nerve-centre/kpi-cards/bring/on-time-delivery-rate) | The carrier-side outcome. | A missed dispatch that still delivered on time is a process near-miss; a missed dispatch that delivered late is a customer-felt failure. The overlap tells you how much slack the network is absorbing for you. | | [Late Shipments](/nerve-centre/kpi-cards/bring/late-shipments) | The carrier-leg late count. | If dispatch misses are low but late shipments are high, the problem is Bring transit, not your warehouse. If both rise together, the warehouse delay is cascading into late delivery. | | [Label Print Failures Spike](/nerve-centre/kpi-cards/bring/label-print-failures-spike) | Upstream cause of no-scan misses. | A label that never printed is a parcel that never shipped. Print failures convert directly into dispatch misses 1 to 2 hours later. | | [Bring Tracking API Unavailable / 5xx](/nerve-centre/kpi-cards/bring/bring-tracking-api-unavailable-5xx) | Why a scan may be missing. | If the Tracking API was down, the first scan may exist at Bring but not in our index yet; reconcile before treating a no-scan as a genuine miss. | | [Mypack Pickup Expiring or SLA Breach](/nerve-centre/kpi-cards/bring/mypack-pickup-expiring-or-sla-breach) | Adjacent SLA-breach alert for Mypack. | Mypack is 70 percent of this merchant's volume; dispatch misses on Mypack parcels feed straight into pickup-expiry risk downstream. | | [Shipments with Tracking-Event Gap](/nerve-centre/kpi-cards/bring/shipments-with-tracking-event-gap) | Stale-shipment companion. | A dispatched parcel that then goes silent in transit is a different failure mode; this card catches the despatch end, that card catches the transit end. | | Cross-connector: [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) | Upstream queue depth. | A climbing unfulfilled count predicts a rising dispatch-miss count 1 to 2 days later. | | Cross-connector: [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) | Downstream impact. | Dispatch misses drive refund and WISMO tickets at a 3 to 10 day lag. | ## Reconciling against the source **Where to look in Bring's own tooling:** [Bring Mybring](https://www.mybring.com/) → **Shipments → Shipment list** for the consignment-level booking and first-scan timestamps, and **Reports → Booking history** for the order-to-booking cadence. The first registered event for each consignment appears in the [Bring Tracking](https://tracking.bring.com/) portal and via the Bring Tracking API. Bring does not publish a "dispatch SLA" report of its own, because the dispatch promise is yours, not Bring's: the carrier only knows when it first scanned the parcel. To reconcile, compare the consignment's first scan time in Mybring against the order's deadline in your store admin. The closest like-for-like check is: export the Mybring shipment list for the period, take the earliest event timestamp per consignment, and compare it to the order's despatch deadline computed from your checkout promise. **Why our number may legitimately differ from a manual Mybring check:** | Reason | Direction | Why | | --------------------------------- | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Carrier-local scan timestamps** | Boundary cases off | Bring stamps scans in Norwegian local time (CET / CEST). Mybring shows local time; the card normalises to UTC and back to your display timezone. An order on a deadline boundary (for example a 15:00 cut-off) can land on different sides of the line if you read the raw Mybring timestamp without timezone conversion. | | **Tracking-event ingestion lag** | Ours can lag | The Bring Tracking API surfaces the first scan within minutes to a few hours of the physical event. A parcel collected 30 minutes ago may not yet show a scan in our index, so a recent order can briefly read as a no-scan miss, then clear on the next sync. | | **Deadline definition** | Either | The card uses the later of your checkout cut-off and Bring's collection cut-off. If your manual check uses only the Bring cut-off, you will count fewer misses than the card, which also enforces your customer-facing promise. | | **Marketplace import timing** | Ours higher | The card scores from the order's true `created_at`, including marketplace orders that imported late. A Mybring-only check sees only booked consignments and misses orders that never got booked in time. | | **Booking failures** | Ours higher | An order whose Bring booking failed has no consignment in Mybring at all, so it is invisible there but counts here as a no-scan miss. This is the most important divergence: the card catches the orders Mybring cannot. | **Cross-connector reconciliation:** | Card | Expected relationship | Causes of legitimate divergence | | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------- | | [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) | Upstream input; unfulfilled orders that miss their cut-off become dispatch misses. | Webhook delays, manual holds, B2B / pre-order flows that legitimately defer despatch. | | [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) | Downstream sentiment proxy. | Refunds have many drivers; dispatch miss is one input among sizing, quality and returns. | ***
Documentation cross-reference (for agencies running multiple carriers) Dispatch-SLA-miss metrics exist with conceptually similar definitions across other carriers. These are not parallel measurements of the same orders. * [`postnord.late-shipments`](/nerve-centre/kpi-cards/postnord/late-shipments) (Nordic carrier peer) * [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) (upstream order queue)
## Known limitations / merchant FAQs **Why does this fire on a single order when other cards use a percentage threshold?** Because a dispatch miss is a broken promise to a specific named customer, not a statistical aggregate. One order at risk is one refund, one ticket, one review. The card is deliberately zero-tolerance so operations sees the breach the moment it happens, then uses the vsP comparison to judge whether the rate is drifting. **An order shows as missed but Bring delivered it on time. Is that a bug?** No. This card measures despatch discipline, not delivery outcome. If the parcel left after its dispatch deadline but the network absorbed the slack and still delivered next day, the customer was lucky, not served on time by design. Pair with [On-Time Delivery Rate](/nerve-centre/kpi-cards/bring/on-time-delivery-rate) to separate near-misses from customer-felt failures. **Most of my misses are no-scan orders. What does that mean?** A no-scan miss is an order past its dispatch deadline with no Bring tracking event at all. Two common causes: the label printed but the parcel was never collected (check [Label Print Failures Spike](/nerve-centre/kpi-cards/bring/label-print-failures-spike)), or the Bring booking failed silently so no consignment exists. No-scan misses are the most urgent because the parcel is physically still with you. **My marketplace channel always looks worse. Why?** Marketplace orders frequently import on a delayed webhook or a polling cycle, so they enter the despatch queue after your warehouse has already worked the morning batch. The dispatch clock starts at the true order time, not the import time, so a late import eats into the despatch window. Fix the import cadence, not the warehouse throughput. **How does the card know my dispatch deadline?** It takes the later of two cut-offs: the handover cut-off for the Bring product (Mypack Collect, home delivery, Bedriftspakke and export products each have their own), and your store's published checkout promise. If you change your checkout cut-off copy, update the deadline configuration so the card scores against your current promise. **Does this include returns?** No. The card is outbound only. Inbound return consignments (Bring Retur products) are excluded because they have no customer-facing despatch promise from you. **What is the playbook when the count and the vsP both jump?** In order: (1) check [Label Print Failures Spike](/nerve-centre/kpi-cards/bring/label-print-failures-spike) and [Bring Tracking API Unavailable / 5xx](/nerve-centre/kpi-cards/bring/bring-tracking-api-unavailable-5xx) for a systems cause; (2) break the misses down by sales channel, a single-channel spike points to an import or integration issue; (3) check whether a Bring collection was missed on any day in the window (a missed collection turns a whole day of on-time picks into dispatch misses); (4) if none of those explain it, the warehouse is under-staffed against volume and needs the queue depth from [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) to size the fix. *** ### Tracked live in Vortex IQ Nerve Centre *Orders with Dispatch SLA Missed* is one of hundreds of KPI pulses Vortex IQ tracks across Bring and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English. [Start for free](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.