For every late shipment - was the delay at the warehouse (ShipBob picked late) or on the carrier (DPDLocal in transit)? Key Metric.
At a glance
For every late DPDLocal parcel, attributes the delay either to the warehouse (ShipBob or other 3PL picked / dispatched the parcel late) or to the carrier (DPDLocal kept the parcel longer in transit than the promised carrier-transit-time). Stops the warehouse-vs-carrier finger-pointing with hard numbers.
Calculation
Calculated automatically from your DPDLocal 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 DTC apparel merchant using ShipBob’s UK Bristol DC + DPDLocal NextDay. ~9,000 parcels per month. Reading 12 Mar 26, trailing 30 days, 280 late shipments out of 9,000.
Card flags carrier-share at 60%, exactly at the alert threshold. Three things to notice:
- The conversation stops being “ShipBob’s fault” or “DPDLocal’s fault”, both have evidence. Without this card, the warehouse and carrier teams blame each other; with it, the merchant has hard numbers for both QBRs.
- 60% carrier-share is the renegotiation trigger. This is the right time to push DPDLocal for service-credit allowances, route adjustments, or to evaluate a parallel UK courier (Royal Mail Tracked, Evri, Yodel) for postcode areas where DPD is structurally slow.
- 31% warehouse-share is a staffing or capacity issue at ShipBob. ShipBob’s per-DC capacity ramps for BFCM but commonly stays staffed at the post-peak baseline through January, exposing a gap in February when a brand promotion drives volume. Pair with SLA Compliance by Warehouse.
Sibling cards merchants should reference together
Reconciling against the vendor’s own dashboard
Where to look in DPDLocal’s dashboard: DPDLocal does not produce this attribution split natively, the carrier only sees its own leg. The 3PL produces its own SLA report (ShipBob Merchant Portal → Performance) which shows the warehouse leg. This Vortex IQ card is the only join. Why your manual calc may differ:
Cross-connector reconciliation:
Known limitations / merchant FAQs
The card disappeared. Why? Theonly_when: has_shipbob_sibling condition went false, ShipBob (or the equivalent 3PL connector) was disconnected or its data flow stalled. Re-check the ShipBob connector health.
My 3PL is not ShipBob. Will the card still work?
Currently the join is hard-coded to ShipBob. The card framework supports any 3PL with dispatch timestamps; adding Veeqo, Mintsoft, ShipHero, or in-house WMS support is a connector roadmap item. If the merchant has a custom WMS export, manual import via the connector field-mapper can populate the equivalent dispatch timestamp.
Carrier-share is at 70% but my account team says they hit 99% transit time. Who’s right?
Both can be right. DPDLocal’s “transit time” report measures depot-to-delivery; this card measures handoff-to-delivery. The gap is the depot-receive-to-depot-out leg, which DPD often does not surface in their report but counts in this card. Show your account team the dispatch_to_delivery_hrs distribution to ground the conversation.
What if the warehouse is fast but the carrier still hits the SLA, does this card still flag warehouse-share?
No. The card only attributes when the parcel is late overall. A fast warehouse + slow carrier that still meets the customer-promise contributes nothing to either share.
Should I switch carriers if carrier-share is high?
Maybe, after evaluating. Three steps. (1) Check whether the carrier-share is concentrated in specific UK postcode areas using OTD by Route; a regional fix may be faster. (2) Renegotiate before switching, the carrier has commercial leverage when you have evidence. (3) If switching is the decision, run a 4-week parallel test on a subset of postcodes to validate the new carrier on your specific route mix before full migration.