At a glance
Share of Bring consignments that hit a non-delivery exception event in the period: held at terminal, address invalid, recipient absent, customs delay, weather hold, or other interruption that breaks the normal “booked → in transit → delivered” flow. Exceptions do not always become late deliveries (most resolve within 24 hours), but a rising exception rate is the leading indicator that next week’s On-Time Delivery Rate and Late Shipments will move down. Treat this as the early-warning dial on Bring carrier health.
| What it counts | COUNT(DISTINCT consignmentNumber WHERE event_code IN exception_codes) / COUNT(DISTINCT consignmentNumber WHERE booked_in_period). A consignment hitting two exceptions counts once; the rate is by parcel, not by event. |
| API endpoint | Bring Tracking API GET /tracking/v3/tracks/{consignmentNumber} event stream. The card pattern-matches on eventCode against the curated exception code-set: held_at_terminal, address_unknown, recipient_absent, delivery_attempted, customs_inspection, weather_delay, damaged_in_transit, lost_in_transit, incorrect_address, recipient_refused. |
| Exception vs late | An exception is an in-transit interruption; a late delivery is the outcome where the parcel arrived after promise. Most exceptions resolve and the parcel still delivers on-time (held-at-terminal often clears in 4 to 12 hours during peak). The relationship is leading-indicator, not equivalence. |
| Climate / weather codes | The Bring tracking feed surfaces weather_delay codes during winter on northern Norwegian routes; these are real and the card includes them. Some merchants exclude weather-related exceptions from operational alerts because they are not actionable; the card reports the gross rate and lets the merchant filter at the alert layer. |
| Service-tier scope | All tracked services with an event stream: Home Delivery Parcel, Pickup Parcel, Business Parcel, Cargo. Mail products and untracked services are excluded because they have no exception events to count. |
| Cross-Border partner exceptions | For non-Nordic destinations the partner-carrier event feed is included where available. Partner feeds are noisier than Bring’s own feed; the card normalises common partner codes (DHL held_at_clearance, PostNord customs_clearance) into the canonical Bring exception set. |
| Returns / RTO | Outbound only. Return-leg exceptions are filtered. RTO volume is on Returned to Sender. |
| Currency | The card is a percentage. To value the exception tail, join with Avg Shipping Cost and an internal CS-cost-per-ticket assumption; an exception costs roughly the same as a late delivery in CS time. |
| Time window | 30D vsP (rolling 30 days, period-over-period). Daily readings are noisy below 200 consignments per day; weekly is the operational cadence. |
| Alert trigger | >3%. Bring’s network typically runs 0.5 to 1.5 percent exception rate domestic Norway, 1.5 to 3 percent Cross-Border Nordic, 3 to 6 percent rest-of-EU. The 3 percent trigger is calibrated to fire on Norwegian-domestic disruption, not on routine Cross-Border noise. |
| Sentiment key | {'type': 'gauge', 'thresholds': {'good': 1, 'warn': 3}} |
| Roles | owner, operations |
Calculation
Calculated automatically from your Bring 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 Drammen-based outdoor-apparel merchant, 15,300 trailing-30-day Bring consignments. Reading taken at 09:00 CET on 11 Mar 26 for the trailing 30 days (10 Feb 26 to 10 Mar 26).| Exception code | Count (distinct consignments) | % of period volume | Median resolution time |
|---|---|---|---|
held_at_terminal | 142 | 0.93% | 8 hours |
recipient_absent (Home Delivery only) | 98 | 0.64% | 22 hours (redelivered or moved to pickup point) |
weather_delay (northern routes) | 71 | 0.46% | 36 hours |
address_unknown | 44 | 0.29% | 48 hours (with merchant intervention) |
customs_inspection (Cross-Border) | 38 | 0.25% | 72 hours |
delivery_attempted (no answer at door) | 24 | 0.16% | 14 hours (collected next day) |
damaged_in_transit | 7 | 0.05% | 96 hours (claim filed) |
lost_in_transit | 3 | 0.02% | not resolved |
| Total exception consignments (this card) | 427 | 2.79% | median 18 hours |
>3% is not tripped, but the trend matters more than the level. Five things to notice:
- Held-at-terminal is the largest bucket and the most resolvable. 142 consignments held at terminal usually means a sortation backlog at one or two specific facilities. If the bulk is at the Oslo Alfaset terminal, a quick peak-shift conversation with the Bring account team typically resolves it; if it is at a partner-handover terminal in Sweden or Denmark the resolution is slower.
- Recipient-absent is structural, not an issue. 98 absent-recipient exceptions on Home Delivery is normal for residential Norway; recipients work, parcels go to pickup point, recipients collect within 48 hours. The healthy reading is around 0.5 to 1 percent of Home Delivery volume; this merchant’s 1.3 percent is within range.
- Weather delay is seasonal noise to annotate, not act on. 71 weather-delay exceptions in March is the tail end of winter; in July this category will read close to zero. Do not re-baseline the alert threshold for weather; instead note the seasonal pattern in the board commentary.
- Address-unknown is the merchant’s problem, not Bring’s. 44 unknown-address exceptions usually trace back to the checkout flow: missing apartment numbers, unit numbers, postcode mismatches. Pair with
shopify.checkout_address_validationor equivalent, and consider a checkout address-validator if the count exceeds 0.4 percent. Each address-unknown exception costs roughly 25 to 45 minutes of CS time to resolve. - Lost-in-transit is the small number that hurts most. 3 lost-in-transit consignments at an average order value of 850 NOK each = 2,550 NOK of refund-or-reship liability, plus 3 angry customers and 3 negative reviews. Treat lost-in-transit as a separate dial; the Open Claims card breaks these out and tracks claim-recovery time.
Sibling cards merchants should reference together
Exception Rate is a leading indicator. Pair it with these to read the signal:| Card | Why pair it with Exception Rate | What the combination tells you |
|---|---|---|
| On-Time Delivery Rate | The downstream outcome dial. | A 3-point exception-rate spike usually shows up as a 1 to 2 point OTD drop 24 to 72 hours later. If exceptions climb but OTD holds, the network is recovering exceptions inside the promise window (good news). |
| Late Shipments | The downstream count. | Exception-to-late conversion is roughly 30 to 50 percent for Norwegian-domestic, 50 to 70 percent for Cross-Border. Multiply expected late by exception delta to forecast next week’s late count. |
| Failed Deliveries | The subset of exceptions that did not recover. | Most exceptions resolve and the parcel still delivers; the unresolved tail becomes a failed delivery, then potentially an RTO. |
| Open Claims | The recovery-and-money side. | Damaged-in-transit and lost-in-transit exceptions become claims; the dollar value sits on the claims card. |
| OTD by Route | Where the exceptions are concentrated. | A network-wide exception spike points to Bring; a route-concentrated exception spike points to a specific terminal or partner depot. |
Cross-connector: shopify.checkout_completion_rate | Upstream cause for address_unknown exceptions. | Checkout flows that do not validate address completeness leak into Bring as address_unknown exceptions; validating at checkout cuts this exception class by 60 to 80 percent. |
Cross-connector: gorgias.tickets_open | Downstream impact. Exceptions drive WISMO and “where is my refund” tickets. | A 1-point exception-rate spike typically maps to a 12 to 18 percent ticket-volume increase at 24 to 72 hours lag. |
Cross-connector: klaviyo.transactional_email_delivery | Defensive comms. Proactive “your parcel had an issue” emails reduce ticket inflow. | Triggering a Klaviyo flow on Bring exception webhooks reduces customer-initiated WISMO tickets by 35 to 55 percent. |
Reconciling against the vendor’s own dashboard
Where to look in Bring’s own portal: Mybring → Statistics → Tracking Events, then filter the event-code dropdown to the exception classes (held-at-terminal, address-unknown, recipient-absent, customs-inspection, weather-delay, damaged, lost). Mybring presents the data as an event count rather than as a per-consignment rate; the card normalises to per-consignment to avoid double-counting. Why our number may legitimately differ from Mybring:| Reason | Direction | Why |
|---|---|---|
| Per-event vs per-consignment counting | Mybring higher | Mybring’s default view counts events; a single consignment hitting held_at_terminal then delivery_attempted then delivered counts as two events in Mybring and one consignment in the card. |
| Exception code curation | Either | Bring’s tracking feed has 60+ event codes; the card’s exception set is curated to operationally meaningful breaks. Codes like arrived_at_sortation_centre are normal in-transit events and excluded. Mybring’s exception view sometimes uses a different curated set. |
| Cross-Border partner code mapping | Ours typically lower | Partner-carrier event feeds use carrier-specific codes; the card maps the major partners (DHL, PostNord, GLS) but unrecognised codes are not counted as exceptions. Mybring may over-count partner events. |
| Resolution-window deduplication | Ours lower for active retries | If a consignment hits the same exception code twice (e.g. delivery_attempted on Tuesday and Wednesday), the card counts it once. Mybring may count both attempts. |
| Timezone (CET / CEST vs UTC) | Boundary days off | Mybring reports in Oslo local time; the card stores in UTC. Across a 30-day window the boundary effect is below 0.05 percentage points. |
| Card | Expected relationship | Causes of legitimate divergence |
|---|---|---|
gorgias.tickets_open | Exceptions feed CS tickets at 12 to 18 percent ticket-volume increase per 1-point exception-rate increase. | Not all tickets relate to Bring; not all Bring exceptions become tickets. Strong directional correlation, no exact identity. |
shopify.checkout_address_validation | Upstream cause for address-unknown exceptions. | Checkout-side validation typo rates and the carrier-side address_unknown exception rate move together; not all merchants have an address validator deployed. |
postnord.pos_exception_rate | Adjacent Nordic carrier exception rate for the same period. | Different carrier, different shipments; cross-compare to monitor both networks during winter or industrial-action incidents. |
Known limitations / merchant FAQs
Should I exclude weather delays from the alert threshold during winter? Reasonable choice. Norwegian winter on northern routes (postcode 90xx and above) generates a structural 0.5 to 1.5 percent weather-delay exception rate from November through March. The card reports the gross rate; configure the alert at the integration layer to either (1) excludeweather_delay from the alert formula during winter months, or (2) raise the threshold from 3 percent to 4 percent for that window. Do not delete weather exceptions from the underlying data; they are real and you may want to comment on the customer-felt experience separately.
My exception rate is 4 percent and OTD is still 96 percent. Is this fine?
Probably yes. The relationship is leading-indicator, not equivalence. If exceptions are running 4 percent but resolving inside the promise window (sortation backlog cleared in 6 hours, recipient-absent collected next morning) the OTD dial is unaffected. Watch the trend: if exception rate keeps climbing while OTD stays flat, you are riding a recovery margin that will eventually exhaust. If OTD starts falling 24 to 72 hours after the exception spike, the recovery margin has run out.
A single warehouse error caused 200 address-unknown exceptions in one day. Is the dial broken?
The dial is reading reality. A label-data export bug or a checkout typo can produce a one-day spike. The card does not auto-smooth; configure your alert to trigger on a 7-day rolling rather than daily reading if one-day spikes are too noisy for your operations cadence. The underlying data should still be fixable: identify the affected consignments via the drill-down, contact Bring to update addresses (the parcels are usually still in network and re-deliverable), and patch the upstream cause.
Why does my Cross-Border exception rate read so much higher than my Norwegian-domestic rate?
Three structural reasons. (1) Customs inspections. EU + Norway is not a frictionless border for parcels above 350 NOK; customs inspections for non-EU origin (or non-Norway-EFTA exemptions) add 1 to 3 percentage points of customs_inspection exceptions. (2) Partner-carrier hand-overs. Each hand-over (Bring → PostNord → DHL last-mile) is an opportunity for a hand-over scan to fail or get logged as an exception. (3) Address-format mismatches. Norwegian, Swedish, Danish, and Finnish postcode formats differ; a checkout that does not validate per-country generates 0.5 to 2 percent extra address-unknown exceptions on cross-border. The fix for (1) is to ensure correct customs-data on the booking; the fix for (2) is structural and outside the merchant’s control; the fix for (3) is a per-country-aware checkout validator.
Held-at-terminal keeps showing up. Should I worry?
Held-at-terminal is the most common exception code and usually the least concerning; it just means the parcel paused at a sortation facility. Concerning patterns: (1) consistently held at the same terminal more than 24 hours, suggesting a local capacity problem, (2) held-at-terminal on the same lane every Monday, suggesting a recurring weekend backlog, (3) held-at-terminal followed by lost-in-transit, suggesting the parcel actually went missing during the hold. Use the drill-down to identify the terminal pattern; raise it with your Bring account team if it is a single-facility issue.
Which exception codes should I treat as actionable vs ignorable?
Actionable (chase same-day): damaged_in_transit, lost_in_transit, incorrect_address (when paired with a high-value consignment), recipient_refused. Actionable (chase within 24 hours): address_unknown, customs_inspection exceeding 48 hours. Monitor only: held_at_terminal, recipient_absent, delivery_attempted, weather_delay. The alert threshold of 3 percent is calibrated to the actionable + monitor mix; if you split the alert into “actionable-only”, set it lower (around 1 percent).
My CS team wants a webhook for new exceptions, not a periodic dashboard read. Is that supported?
Yes. Configure the Bring webhook integration to push exception events to your CS tool (Gorgias, Zendesk, etc.) with eventCode IN exception_set as the filter. Pair with Klaviyo Transactional Email to send a proactive customer email on the same trigger. The card itself reads from the same event stream; webhook + dashboard reads are consistent.
The dial dropped from 2.8 percent to 0.4 percent overnight. Did the network suddenly improve?
Probably not. Most overnight dial drops on this card are data-feed issues, not network improvements. Three things to check: (1) is the Bring tracking-API integration still authenticated (see Days to Token Expiry), (2) is the booking-API integration still posting (a missing booking flow means newer parcels are not in the denominator), (3) is there a consignment-number mismatch between booking and tracking (a recent service-code rename can break the join). If all three are healthy and the drop is real, double-check by comparing against Late Shipments; the two should move in directionally consistent ways.
Is the 3 percent threshold suitable for a B2B-heavy merchant?
Mostly yes. Bring Business Parcel Bulk B2B has a structurally lower exception rate than residential (roughly 0.5 to 1 percent vs 1 to 2 percent for residential) because B2B receivers are at fixed addresses with goods-in operations. A B2B-heavy merchant might tighten the alert to 2 percent. A B2C-heavy merchant on Cross-Border is comfortably above 3 percent on a normal week and may need to loosen to 4 percent or split per-route.