> ## 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. # APC OTD by Sales Channel, APC Overnight > Per-channel APC OTD. How to read it, why it matters, and how to act on it. **Metrics type:** [Cross-Platform Metrics](/nerve-centre/overview#metrics-types-explained) • **Category:** [Shipping & Courier](/nerve-centre/connectors#connectors-by-type) > Per-channel APC OTD. ## At a glance > APC on-time delivery rate split by the *originating sales channel* (Shopify, BigCommerce, Adobe Commerce, EDI / B2B-direct, marketplaces). The card derives the channel attribution by joining APC consignment records to the upstream order's source-channel tag, then computes OTD% per channel. The point: if your APC service is healthy on average but one channel is consistently failing, the right action is mix-shift or channel-specific dispatch fixes, not a network-wide carrier conversation. | | | | ------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **What it counts** | For each known channel, `COUNT(APC shipments WHERE channel=X AND POD_timestamp <= promised_cutoff) / COUNT(APC shipments WHERE channel=X AND has_final_scan)` over 30 days. Reported per-channel with the worst-performing channel highlighted. | | **Channel attribution source** | Order-source tag from the upstream connector. Shopify uses `Order.sourceName`; BC uses `order.channel_id`; Adobe Commerce uses store\_id mapping; B2B/EDI orders are tagged at booking time. Vortex IQ joins these to APC consignment records via `customer_reference` (the merchant's order number passed into the APC booking). | | **Delivery success criterion** | Same as `apc_otd_rate`: APC POD scan timestamp at or before the promised cutoff *time* on the promised *day*. Each shipment scores 0 or 1, then aggregated per channel. | | **Service level scope** | All APC services pooled inside each channel. A channel that ships 80% NextDay-12 and 20% NextDay anytime gets the blended rate. To split further, drill into `apc_otd_rate` filtered by service. | | **Channel-mix interpretation** | High-cost-per-OTD-percentage-point usually identifies the channel where APC is least suited. A B2B EDI channel running 99.2% OTD validates the premium cost; a marketplace channel running 91.4% OTD on the same network suggests dispatch-cutoff or address-data hygiene issues at that channel's order ingestion. | | **Money-back-on-late attribution** | Service-failure refunds from APC are recovered against APC. They are not allocated to the originating channel automatically. Pair this card with `apc_open_claims` and report channel-attributed claim recoveries manually if the merchant tracks margin per channel. | | **B2B vs B2C channel split** | Most merchants find their B2B / EDI channels run higher OTD on APC than their B2C / DTC channels, despite the tighter promised SLAs. This is because B2B orders are typically captured earlier in the day, batched cleanly, and shipped to better-curated address books. DTC channels handle late-afternoon impulse orders, novel addresses, and access-instruction gaps. | | **Channel-mix changes warp the read** | Adding a new marketplace channel that ships 500 weekly parcels mid-month dilutes the aggregate `apc_otd_rate` and shows up as a new low-performing column on this card. Read this card alongside channel volume; a 91% rate on 5 shipments is statistical noise, on 500 shipments is real. | | **Time zone** | UK local time for the promised-cutoff comparison; channel-tag timestamps come from each upstream connector's native time zone (Shopify uses store time zone; BC uses store time zone; B2B EDI uses UK local). The card normalises to UK local for the OTD comparison. | | **Time window** | `30D` (rolling 30 days). Long enough to absorb single-day weather events; short enough to surface mix-driven drift. | | **Alert trigger** | `any channel <90%`, the card flips amber as soon as one channel's OTD% drops below 90 percent, regardless of aggregate health. The point of this card is to surface the channel that is dragging. | | **Sentiment key** | `on_time_delivery_rate` | | **Roles** | owner, operations, marketing | ## Calculation Calculated automatically from your APC Overnight data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading. ## Worked example A UK premium homewares merchant: £140 average-order-value, sells through three channels (Shopify DTC website, a curated marketplace channel that takes 30%+ of recent volume, and a small B2B trade book to interior-design studios). APC NextDay-12 is the primary service across all three. Reading taken at 09:00 GMT on 12 Mar 26 for the trailing 30 days (10 Feb 26 to 11 Mar 26). | Channel | APC shipments (30D) | Delivered on/before APC promised cutoff | OTD % | Notes | | ---------------------------- | ------------------- | --------------------------------------- | --------- | ---------------------------------------------------------------------------------------- | | Shopify (DTC website) | 2,340 | 2,267 | 96.9% | Healthy. Includes occasional rural Scotland addresses. | | Curated marketplace | 1,180 | 1,055 | 89.4% | **Below the 90% alert threshold.** Marketplace ingests addresses with looser validation. | | B2B / Trade direct | 410 | 408 | 99.5% | Very healthy. EDI-fed, batched at 14:00, perfect addresses. | | **All channels (aggregate)** | **3,930** | **3,730** | **94.9%** | Aggregate looks fine; one channel is amber. | The card flips amber on **89.4% (Marketplace)**. Five things to notice: 1. **The aggregate hides the mix problem.** 94.9% on the all-channel `apc_otd_rate` looks acceptable; reading this card surfaces that one in nine marketplace parcels is missing its APC promise. That is a customer-experience pattern, not a one-week blip. 2. **Marketplace addresses are less reliable than DTC addresses.** Marketplace platforms typically pass through customer-supplied address-line-1 and -2 with minimal validation. A "Flat 3, behind the chemist, 24 High Street" parcel from Shopify checkout (validated) is not the same as the same parcel from a marketplace order (un-validated). Address-data hygiene is the most common root cause of channel-OTD divergence. 3. **The right next action is at the marketplace order-ingestion layer, not APC's depot network.** Tightening address validation on the marketplace order import (postcode-API lookup, manual CSR review of fragile addresses) typically lifts the channel's OTD by 2 to 4 points without any APC-side change. 4. **The B2B channel at 99.5% validates the APC premium.** The same network that is at 89.4% on marketplace is at 99.5% on B2B with the same SLA promise. APC is not the problem; the order-data pipeline is. Use the B2B reading as the network-baseline benchmark. 5. **Compare against same-period last year.** If marketplace was at 95.1% on 12 Mar 25 and is at 89.4% on 12 Mar 26, the regression is recent. Most likely cause: the marketplace platform changed its address-import format, or volume grew faster than CSR address-validation capacity. Mid-month launches of new marketplace channels show this pattern in the first 30 days. **Revenue-at-risk read:** roughly 125 marketplace parcels in the period missed the promise. At a £140 AOV with \~30% margin and a 5-percentage-point lift in repurchase risk per failed delivery, that is roughly £262 of margin-loss exposure on this category alone over 30 days, plus £30+ in recoverable APC carriage refunds the merchant has not filed. Not catastrophic; absolutely actionable. ## Sibling cards merchants should reference together This card is most useful read with channel-revenue and APC-network cards together: | Card | Why pair it with APC OTD by Channel | What the combination tells you | | ----------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------- | | [On-Time Delivery Rate](/nerve-centre/kpi-cards/apc/on-time-delivery-rate) | The all-channel aggregate. | If aggregate is 95% and one channel is 89%, the channel is dragging. If both are 89%, it is a network issue, not a channel-mix one. | | [NextDay 9am Service Promise](/nerve-centre/kpi-cards/apc/nextday-9am-service-promise) | The premium-service slice. Pair to confirm whether the failing channel is concentrated on premium services. | If marketplace is 89% on aggregate but 98% on 9am, the failures concentrate in NextDay anytime; the customer impact is lower than it looks. | | [Failed Deliveries](/nerve-centre/kpi-cards/apc/failed-deliveries) | Absolute count of failures inside the failing channel. | A 91% rate on 50 shipments is 4.5 failed; on 500 shipments it is 45. Volume scales the urgency. | | [Open Claims](/nerve-centre/kpi-cards/apc/open-claims) | The recovery side. Service-failure refunds get filed against APC; channel-attributed refunds need to be reported separately. | Filing rate × failure rate per channel = recovered revenue per channel. Useful when you are reporting margin-by-channel. | | Cross-connector: [`shopify.shipments_late_pct`](/nerve-centre/shopify/shipments_late_pct) | Same-shape metric on the Shopify side, pre-carrier. | If Shopify's pre-handoff late% is healthy but APC's post-handoff Shopify-channel OTD is poor, the lag is between dispatch and APC handoff. | | Cross-connector: [`bigcommerce.shipments_late_pct`](/nerve-centre/bigcommerce/shipments_late_pct) | Same on BC. | Same logic; useful for multi-platform merchants. | | Cross-connector: [`google_analytics.ga_channel_revenue`](/nerve-centre/google_analytics/ga_channel_revenue) | Channel-revenue weights. The cost of a 91% OTD on a £30k/month marketplace channel is much bigger than 91% on a £3k/month one. | Revenue × failure-cost-multiplier per channel = which channel to fix first. | | Cross-connector: customer NPS / review-platform feed | Downstream sentiment per channel. | Marketplace-channel-specific NPS dips correlate with this card's per-channel OTD; the survey is the lagging confirmation. | ## Reconciling against the vendor's own dashboard **Where to look in APC's own portal:** [APC Overnight Customer Portal](https://www.apc-overnight.com/) → **Track & Trace → Reports → Service Performance**, then export the consignment list as CSV. APC's portal does not split by sales channel natively (APC has no concept of "marketplace vs DTC"); the channel attribution is a Vortex IQ derivation. To reconcile: 1. Export APC's CSV of consignments + POD outcomes for the period. 2. In your order-management system (Shopify Admin, BC Admin, or your ERP), pull the same period's orders with channel tagged. 3. Join on `customer_reference` (the merchant's order number passed into APC's booking). Group by channel. 4. Compute on-time/total per channel. The card automates this join. The portal can support it manually, but only the merchant has the channel mapping. For account-managed customers, the APC monthly Service Performance Report (SPR) does not split by channel. APC cannot, the channel-tag does not exist on their side. The merchant's BI team has to do this join; this card replaces that workstream. **Why our number may legitimately differ from a manual reconciliation:** | Reason | Direction | Why | | ----------------------------- | ----------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Channel-tag join failures** | Either | If `customer_reference` doesn't match between Shopify's order ID and APC's consignment booking, the parcel is "channel = unknown" and excluded from the per-channel rate. Common when warehouse staff edit the consignment reference manually. | | **Order-cancellation timing** | Ours higher | Cancelled orders that were already booked into APC are still tracked at APC; if the channel-attribution comes from an order that was later cancelled, the row may be filtered out at our layer but still tracked at APC's layer. | | **Multi-channel orders** | Either | A small fraction of orders have ambiguous channel-attribution (e.g. a Shopify order tagged with a marketplace source). Vortex IQ uses the most authoritative tag (Shopify's `Order.sourceName`); your manual reconciliation might pick a different one. | | **Channel-renaming events** | History gaps | If a channel was renamed mid-month (e.g. "TikTok Shop UK" → "TikTok Shop"), historical rows show the old name; new rows show the new. The card consolidates known aliases automatically; novel rename events may need manual mapping in the connector config. | | **B2B orders not tagged** | Channel = B2B / unknown | B2B orders that are placed via phone or email and entered manually into the OMS may not have a channel tag at all. They land in "Unknown" or "Direct" channel. Tag B2B orders explicitly to keep this card accurate. | **Internal identity (within APC):** `weighted-average(channel-OTD% × channel-volume) = apc_otd_rate aggregate`. The per-channel rates and the network aggregate must reconcile to within a rounding tolerance of ±0.1 percentage points. Larger gaps point to channel-attribution failures (orders with no channel tag), which surface as "Unknown" channel volume. * [`apc.apc_otd_rate`](/nerve-centre/kpi-cards/apc/on-time-delivery-rate), the all-channel aggregate * [`apc.apc_shipments_total`](/nerve-centre/kpi-cards/apc/shipments), the volume base **Cross-connector reconciliation:** | Card | Expected relationship | What causes legitimate divergence | | -------------------------------------------------------------------------------- | --------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------ | | [`shopify.shipments_late_pct`](/nerve-centre/shopify/shipments_late_pct) | Pre-carrier (warehouse-floor) version of late% on the Shopify channel only. | Shopify counts orders not shipped by promised dispatch; this card counts orders not delivered by promised arrival. The two should track loosely. | | [`bigcommerce.shipments_late_pct`](/nerve-centre/bigcommerce/shipments_late_pct) | Same on BC. | Same logic. | | Channel-specific NPS / CSAT survey results | Downstream sentiment. Per-channel OTD predicts per-channel CSAT. | NPS surveys are channel-specific; if marketplace NPS is dropping while DTC NPS is stable, this card likely shows the same pattern. | ***
Documentation cross-reference (for agencies running multiple shippers across channels) The "carrier OTD by sales channel" cross-platform card exists for every premium UK shipper. The pattern is identical; the cards are independent because the carrier accounts are independent. Cross-link only. * [`parcelforce.parcelforce_xc_otd_by_channel`](/nerve-centre/kpi-cards/parcelforce/parcelforce-otd-by-sales-channel), Royal Mail's express arm. * [`interlink_express.interlink_xc_otd_by_channel`](/nerve-centre/kpi-cards/interlink-express/interlink-otd-by-sales-channel), DPD group's premium UK service. Multi-shipper merchants typically route different channels to different carriers (e.g. APC for B2B 9am, Parcelforce Express48 for marketplace, Royal Mail Tracked-24 for low-AOV DTC). Each carrier's xc-OTD card surfaces a different mix issue; reading them together reveals which channel-carrier pairings are working and which need re-routing.
## Known limitations / merchant FAQs **Why is one of my channels showing "Unknown" with high volume?** Most likely: the order's source-channel tag is not being passed through to APC's `customer_reference`, or the merchant's OMS is using a different reference number on each side of the join. Two fixes. (1) Audit the OMS-to-APC integration so that the order's source channel is captured and the consignment reference is the order ID. (2) For B2B orders entered manually, add a "Channel: B2B" tag in the OMS. The card consolidates over time as the data improves. **My marketplace channel is below 90% but my Shopify is fine. Is APC the problem?** No. If APC's network were the problem, both channels (and B2B) would be amber. The fact that the underlying APC service is at 99.5% on B2B and 96.9% on Shopify tells you the network is healthy; the marketplace channel is failing for channel-specific reasons. Most common causes: (a) address-data hygiene on marketplace ingestion, (b) marketplace-specific dispatch-cutoff slippage, (c) marketplace customers ordering items APC has no rate negotiated for and being dispatched on a sub-optimal service. Investigate at the channel layer, not at APC. **How is sales channel attributed to an APC parcel?** The merchant's OMS or e-commerce platform passes the order's source-channel tag through to the APC consignment booking via `customer_reference` (the merchant's order number). Vortex IQ joins APC consignment records back to the upstream order on this reference. If the join fails, the parcel lands in "Unknown" channel. **My APC contract is per-shipment, not per-channel. Why do I care about per-channel OTD?** Two reasons. (1) **Customer experience asymmetry.** A 90% OTD on a low-AOV marketplace channel is much less damaging than a 90% OTD on a high-AOV B2B channel; you need to know which is which. (2) **Channel-mix decisions.** If marketplace OTD on APC is consistently 5+ points below DTC, the right answer may be to move marketplace volume to a different carrier (e.g. Royal Mail Tracked-24) where the lower SLA matches the lower customer expectation, freeing APC capacity for high-AOV DTC and B2B where the premium pays back. **Does this card include returns and RTO?** No. Returns to sender are tracked on `apc_returned_to_sender` and excluded here. The card scores outbound delivery only. **Why does the alert trigger on `any channel <90%` and not on aggregate?** Because the cost of the failure is concentrated in the channel that fails. A 95% aggregate that hides an 80% B2B-EDI channel is a bigger fire than a steady 92% across all channels. The alert is set to surface the single worst-performing channel, regardless of aggregate. **My channel mix is unstable, the worst channel each week is different. Is the card useful?** Yes, but read it with volume context. A channel that lands at 88% on 12 shipments in a quiet week is statistical noise; the same on 1,200 shipments is real. The card includes a volume column for this reason; the alert can be tuned per-workspace to ignore channels with \<50 shipments. **What if I want APC OTD for a specific marketplace, not "Marketplaces" pooled?** Filter `apc_shipments_by_destination` or `apc_shipments_by_service` by the specific source tag. The card here pools "Marketplaces"; per-marketplace splits are on the roadmap and can be unlocked by adding granular channel mappings in the integration config. **Should I publish per-channel OTD% to my marketplace partners?** Cautiously yes. Most marketplaces have their own seller-rating SLA (e.g. Amazon's "On-Time Delivery Rate" KPI in seller central). If your APC OTD on that marketplace's channel correlates with the marketplace-side rating, the card is the operational diagnostic; the marketplace's own rating is the contractual one. Use this card to act, the marketplace's rating to comply. *** ### Tracked live in Vortex IQ Nerve Centre *APC OTD by Sales Channel* is one of hundreds of KPI pulses Vortex IQ tracks across APC Overnight 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.