For every late shipment - was the delay at the warehouse (ShipBob picked late) or on the carrier (DPDLocal in transit)? Hero.
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.
| What it counts | Per late shipment, computes warehouse_to_dispatch_hrs (3PL pick → carrier handoff) vs dispatch_to_delivery_hrs (carrier handoff → final delivery). Compares each against the promised target; whichever leg overshoots is attributed the delay. |
| Source data | dpdlocal.shipment.ship_date joined to shipbob.shipment.warehouse_dispatch on fulfillment_id. Generalises to any 3PL connector exposing warehouse-dispatch timestamps. |
only_when: has_shipbob_sibling | Card only renders when ShipBob (or equivalent 3PL with dispatch timestamps) is connected. |
| Mixed-attribution shipments | Where both legs overshoot, attribution is by overshoot magnitude (the worse offender takes the row). The minority leg is logged for the Exception Reasons drill-through. |
| Time window | 30D |
| Alert trigger | carrier-share >60% of late shipments. Carrier-side becoming the dominant cause is a renegotiation lever; 3PL-dominant is an internal staffing / capacity fix. |
| Roles | owner, operations |
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.| Attribution | Late count | Share |
|---|---|---|
| Warehouse (ShipBob picked late) | 88 | 31% |
| Carrier (DPDLocal in-transit overshoot) | 168 | 60% |
| Mixed (both legs late) | 24 | 9% |
- 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
| Card | Why pair |
|---|---|
| Late Shipments | The numerator this card splits. |
| On-Time Delivery Rate | The percentage view. |
| SLA Compliance by Warehouse | ShipBob-side detail when warehouse-share is dominant. |
| OTD by Route | DPDLocal-side detail when carrier-share is dominant. |
| Exception Reasons | The reason mix on each leg. |
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:| Reason | Direction | Why |
|---|---|---|
| Timestamp granularity | Either | ShipBob’s warehouse_dispatch event is at the minute; DPDLocal’s firstScan is at depot scan-in (typically 15 to 60 minutes after handoff). Edge cases at the leg boundary may misattribute by 1 to 2 hours. |
| Multi-leg journeys | Either | Hub-and-spoke routes with intermediate depot transfers count as one carrier leg in this card; if a delay was at the hub specifically, the card cannot break it out further. |
| Card | Expected relationship |
|---|---|
| SLA Compliance by Warehouse | The warehouse-side “ground truth”; should reconcile with the warehouse-share of late shipments here. |
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.