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 aggregate hides the mix problem. 94.9% on the all-channel
apc_otd_ratelooks 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. - 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.
- 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.
- 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.
- 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.
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 | 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 | 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 | 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 | 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 | 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 | Same on BC. | Same logic; useful for multi-platform merchants. |
Cross-connector: 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 → 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:- Export APC’s CSV of consignments + POD outcomes for the period.
- In your order-management system (Shopify Admin, BC Admin, or your ERP), pull the same period’s orders with channel tagged.
- Join on
customer_reference(the merchant’s order number passed into APC’s booking). Group by channel. - Compute on-time/total per channel.
| 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. |
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, the all-channel aggregateapc.apc_shipments_total, the volume base
| Card | Expected relationship | What causes legitimate divergence |
|---|---|---|
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 | 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. |
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’scustomer_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.