> ## 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. # Exception Rate, Sendle > Exception Rate for Sendle stores. Tracked live in Vortex IQ Nerve Centre. How to read it, why it matters, and how to act on it. **Metrics type:** [Key Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Exceptions & Claims](/nerve-centre/connectors#connectors-by-type) ## At a glance > Share of Sendle parcels that recorded any non-progress tracking event in the trailing 30 days, compared period-over-period. An exception is any tracking state that diverges from the normal pickup-to-delivery path: failed pickup, address problem, held at depot, recipient unavailable, damaged, lost, or returned to sender. This is the early-warning signal that predicts a falling [On-Time Delivery Rate](/nerve-centre/kpi-cards/sendle/on-time-delivery-rate) 24 to 72 hours before it shows, and the customer-service ticket wave that follows. | | | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | `COUNT(parcels WHERE EXISTS(tracking_event IN exception_set)) / COUNT(parcels shipped)` over the rolling 30-day window. Each parcel scores once even if it threw several exceptions in transit. | | **Data source** | Sendle public API. The card reads the parcel list from `GET /api/orders` and the per-parcel event stream from `GET /api/tracking/{sendle_reference}`, classifying each scan's `status` / `description` field into the exception set. | | **Exception set** | `Pickup Attempted`, `Pickup Failed`, `Address Issue` / `Unable to Locate`, `Delivery Attempted` (card left), `Held at Depot`, `Damaged`, `Lost`, `Return to Sender`, `Cancelled in Transit`. Normal-path states (`Booking Created`, `Info Received`, `In Transit`, `Out for Delivery`, `Delivered`, `Left in a Safe Place`) are excluded. | | **Pickup vs drop-off** | Both included. Pickup parcels (a Sendle driver collects from the merchant) can throw a `Pickup Failed` exception that drop-off parcels cannot; this is the single biggest driver of Sendle exception rate and the reason it can read higher than a pure drop-off carrier. | | **Return-leg inclusion** | **Outbound only.** Return parcels booked through Sendle carry `direction = return` and are filtered out. Return-leg exceptions are surfaced on [Returned to Sender](/nerve-centre/kpi-cards/sendle/returned-to-sender). | | **Service-tier scope** | All Sendle products pooled: AU domestic (metro and regional zones) and US domestic (5-zone tier). The Sendle tracking event model is single-vendor, so every parcel reports against one taxonomy regardless of the partner courier (Couriers Please, Aramex partners, USPS-partnered routes). | | **Geographic scope** | All Sendle lanes. Scan timestamps are recorded in carrier-local time (AEST/AEDT for AU, recipient-local for US), normalised to UTC on ingest. | | **In-flight and recovered handling** | A parcel still in transit with no exception scan is excluded from the numerator but stays in the denominator. A parcel that threw an exception and later delivered still counts: the customer felt the friction even though it arrived. | | **Time window** | `30D vsP` (rolling 30 days, compared to the previous 30 days). Daily readings are noisy below 150 parcels per day. | | **Alert trigger** | `>3%` of total parcels in the period. For a merchant shipping 2,000 Sendle parcels a month, that is 60+ exceptioned parcels. | | **Roles** | owner, operations | ## Calculation Calculated automatically from your Sendle data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example An Australian DTC skincare brand based in Brunswick, Melbourne, shipping around 2,100 parcels a month, all on Sendle. Roughly 70 percent pickup (the Sendle driver collects from the studio each afternoon) and 30 percent drop-off at the local newsagent partner point on overflow days. Reading taken at 09:00 AEST on 14 Apr 26 for the trailing 30 days (15 Mar 26 to 14 Apr 26). Exception breakdown: | Exception state | Parcels (30D) | Share of shipped | | ----------------------------------------- | ------------- | ---------------- | | Pickup Failed | 31 | 1.5% | | Address Issue / Unable to Locate | 14 | 0.7% | | Delivery Attempted (card left) | 9 | 0.4% | | Held at Depot | 6 | 0.3% | | Damaged | 2 | 0.1% | | Return to Sender | 4 | 0.2% | | **Total exceptioned parcels (this card)** | **66** | **3.1%** | Total shipped in the window: 2,130 parcels. The card reads **3.1 percent** on the gauge and the alert at `>3%` is **just** tripped. Five things to notice: 1. **Pickup Failed is half the problem.** 31 of the 66 exceptions are failed pickups, and pickup-driven exceptions are the signature of the Sendle network: when driver coverage in a postcode is thin, the driver does not arrive, the parcels sit, and the whole afternoon's queue slips a day. This is a collection failure upstream of delivery, not a delivery failure. Pair this card with [Pickup Booking Success Rate](/nerve-centre/kpi-cards/sendle/pickup-booking-success-rate) to confirm whether the failed pickups cluster on specific days or postcodes. 2. **The vsP comparison is what makes 3.1 percent actionable.** If last period read 2.4 percent, a jump to 3.1 percent is a 0.7-point deterioration and worth investigating now. If last period read 3.0 percent, this is flat and the alert is noise. Always read the gauge against its own previous-period number, not against an absolute target. 3. **66 exceptions is roughly 66 customer-service contacts in flight.** At an estimated 7 minutes per WISMO contact, that is about 8 staff-hours of work generated this month by exceptions alone. The count, not the percentage, is the operational workload: see [Failed Deliveries](/nerve-centre/kpi-cards/sendle/failed-deliveries) for the deliverability-specific subset. 4. **The damaged and lost tail converts to claims.** The 2 damaged parcels and any lost parcels are the population that becomes a Sendle cover claim. Sendle includes cover (the standard tier carries cover up to AUD 1,500 per parcel, higher on Premium); check [Open Claims](/nerve-centre/kpi-cards/sendle/open-claims) and [Claim Value (open)](/nerve-centre/kpi-cards/sendle/claim-value-open) to see how much of the exception tail has escalated. 5. **Triage by cost-of-exception, not raw count.** A failed pickup costs the merchant a re-book and a day; a damaged parcel costs a replacement plus a claim plus a review. Address Issue exceptions are often self-inflicted (bad checkout address data) and the cheapest to fix at source, so they are the highest-return lever even though they are not the highest count here. ## Sibling cards merchants should reference together Exception rate is the leading indicator. Pair it with these to diagnose and cost the friction: | Card | Why pair it with Exception Rate | What the combination tells you | | ----------------------------------------------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------- | | [On-Time Delivery Rate](/nerve-centre/kpi-cards/sendle/on-time-delivery-rate) | The downstream outcome the exception predicts. | Exception rate leads OTD by 24 to 72 hours. A rising exception rate predicts an OTD dip 2 to 3 days later. | | [Failed Deliveries](/nerve-centre/kpi-cards/sendle/failed-deliveries) | The deliverability subset of the exception set. | Exception Rate includes pickup and depot states; Failed Deliveries isolates the last-mile failures the recipient actually felt. | | [Pickup Booking Success Rate](/nerve-centre/kpi-cards/sendle/pickup-booking-success-rate) | The single biggest exception driver on the Sendle network. | If exception rate rises and pickup success falls in lockstep, the problem is driver coverage, not delivery. | | [Open Claims](/nerve-centre/kpi-cards/sendle/open-claims) | How many exceptions escalated into cover claims. | Typical conversion is 5 to 15 percent: 60 exceptions produces 3 to 9 claims, mostly from the damaged / lost tail. | | [Claim Value (open)](/nerve-centre/kpi-cards/sendle/claim-value-open) | The dollar value sitting in those claims. | Converts the exception count into money at risk under Sendle cover. | | [Returned to Sender](/nerve-centre/kpi-cards/sendle/returned-to-sender) | The Return to Sender slice of the exception set. | RTS parcels are exceptions that consumed full outbound and return cost for zero delivery. | | [First-Attempt Delivery Rate](/nerve-centre/kpi-cards/sendle/first-attempt-delivery-rate) | The inverse signal: parcels delivered cleanly first time. | A falling first-attempt rate and a rising exception rate are two views of the same deterioration. | | Cross-connector: [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) | Downstream financial impact. | A multi-point exception spike typically precedes a refund-rate rise 7 to 14 days later. | ## Reconciling against the source **Where to look in Sendle's own tooling:** The [Sendle Dashboard](https://www.sendle.com/) → **Orders** view is the merchant's source of record. Filter the order list by status (Sendle exposes `Pickup Failed`, `Delivery Attempted`, `Held`, `Damaged`, `Lost`, `Cancelled` as filterable states) and set the range to *Last 30 Days*. The per-parcel **Tracking** page shows the full scan history for any single parcel, which is the same event stream the card classifies. The Sendle Tracking API (`GET /api/tracking/{sendle_reference}`) returns the identical events programmatically. The closest like-for-like view is *All Orders, Last 30 Days, status in the exception set, outbound only*. **Why our number may legitimately differ from Sendle's dashboard:** | Reason | Direction | Why | | --------------------------------- | ----------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Tracking-event latency** | Ours can lag | Sendle pushes scans into the Tracking API in batches; latency from a driver's handheld scan to API visibility ranges from a few minutes to several hours, longer during peak. A parcel that threw an exception 20 minutes ago may not be classified yet. The dashboard sometimes sees it first because it reads Sendle's internal event bus directly. | | **Carrier-local scan timestamps** | Boundary days off | Scan timestamps are recorded in carrier-local time (AEST/AEDT in Australia, recipient-local for US lanes). The card normalises to UTC. For a 30-day window, boundary-day shifts move a handful of parcels between days; the period total agrees within about 1 percent. | | **Recovered-exception counting** | Ours higher | The card counts a parcel that threw an exception and later delivered as an exception (the customer felt the friction). Sendle's order list defaults to current status, so a recovered parcel reads as `Delivered` and is easy to miss when eyeballing the dashboard. | | **Exception-set definition** | Either | The card's exception set is an explicit allow-list of states. If Sendle introduces or renames a tracking state, the card may classify it differently from the dashboard's own grouping until the mapping is updated. | | **Pickup vs delivery scope** | Ours higher | The card includes `Pickup Failed` in the exception set. A merchant filtering the Sendle dashboard for delivery exceptions only will see a lower number. | **Cross-connector reconciliation:** | Card | Expected relationship | Causes of legitimate divergence | | ---------------------------------------------------------------------------------- | --------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------- | | [`shopify.refund_rate`](/nerve-centre/kpi-cards/shopify/refund-rate) | Downstream sentiment proxy. Exceptions drive refunds at 7 to 14 day lag. | Refund rate has many drivers (sizing, quality, change of mind); shipping exceptions are one input. | | [`shopify.unfulfilled_orders`](/nerve-centre/kpi-cards/shopify/unfulfilled-orders) | Upstream input. Orders that sit unfulfilled cannot throw a carrier exception yet. | Webhook delays, manual fulfilment, pre-orders. | ***
Documentation cross-reference (for agencies running multiple carriers) Exception-rate metrics exist with conceptually similar definitions across other shipping connectors, but the underlying event taxonomy differs per carrier. These are not parallel measurements of the same parcels; use them for navigation, not for cross-carrier reconciliation. * [`auspost.exception_rate`](/nerve-centre/kpi-cards/auspost/exception-rate) (AU national carrier peer) * [`easypost.exception_rate`](/nerve-centre/kpi-cards/easypost/exception-rate) (multi-carrier aggregator peer)
## Known limitations / merchant FAQs **Why is my Sendle exception rate higher than the courier I used before?** Pickup. Sendle's model leans on driver pickup from the merchant, and a failed pickup counts as an exception here even though no delivery has been attempted. A drop-off-only carrier never throws a `Pickup Failed` state. If you compare like-for-like by filtering to delivery exceptions only, the gap usually narrows. The right comparison is exception rate against your own historical Sendle baseline, not against a carrier with a different collection model. **A parcel threw an exception but it arrived fine. Why does it still count?** Because the customer felt the friction. A `Delivery Attempted` card-left exception means the recipient had to arrange redelivery or visit a collection point, even if the parcel arrived a day later. The card measures friction, not just final-state failure. If you only care about parcels that never arrived, read [Failed Deliveries](/nerve-centre/kpi-cards/sendle/failed-deliveries) and [Returned to Sender](/nerve-centre/kpi-cards/sendle/returned-to-sender) instead. **What is the playbook when the gauge crosses 3 percent?** In order: (1) check [Pickup Booking Success Rate](/nerve-centre/kpi-cards/sendle/pickup-booking-success-rate), failed pickups are the most common Sendle exception driver and the first thing to rule out; (2) check whether the exceptions cluster on specific postcodes or zones via [OTD by Route](/nerve-centre/kpi-cards/sendle/otd-by-route), a regional driver-coverage gap is local, a network-wide rise is systemic; (3) check [Open Claims](/nerve-centre/kpi-cards/sendle/open-claims) to see how much of the tail is damaged or lost; (4) if pickup and route are clean, raise a ticket with Sendle support and attach the Orders export for the affected window. **How much tracking latency should I expect before this card is accurate?** Treat anything inside the last 2 to 3 hours as provisional. Sendle's scan-to-API latency is usually minutes but stretches to several hours at peak. The 30-day rolling window absorbs this; the "today" slice does not. Do not act on a single intra-day reading. **Does a cancelled-in-transit parcel count as an exception?** Yes, if Sendle records a `Cancelled in Transit` scan. A parcel cancelled before any pickup scan (still `Booking Created`) is not an exception, it never entered the network. The distinction matters: pre-pickup cancellations are merchant-side admin, in-transit cancellations are network events. **Why does the count bounce day to day even when the rate is steady?** Volume seasonality. A DTC merchant ships 30 to 50 percent more on the two days after a campaign send, so a steady 3 percent exception rate produces a visibly higher count on those days. Use the 30-day rolling reading for trend and the daily slice only for outage detection. **Can I exclude pickup failures from this card?** Not on this card; the exception set is fixed so the number is comparable across merchants. To see deliverability without the pickup leg, read [Failed Deliveries](/nerve-centre/kpi-cards/sendle/failed-deliveries) (delivery-side only) and [Pickup Booking Success Rate](/nerve-centre/kpi-cards/sendle/pickup-booking-success-rate) (collection-side only) side by side. *** ### Tracked live in Vortex IQ Nerve Centre *Exception Rate* is one of hundreds of KPI pulses Vortex IQ tracks across Sendle 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.