OnBuy Orders via ShipBob (SLA), OnBuy

Metrics type: Cross-Platform Metrics • Category: Marketplace

OnBuy SLA compliance specifically for orders fulfilled by ShipBob, isolates 3PL performance per channel.

At a glance

Dispatch SLA compliance limited to OnBuy orders fulfilled by ShipBob (the merchant’s 3PL), isolating 3PL performance per channel from the merchant’s own warehouse performance. Lets ops separate “is OnBuy slow because we are slow” from “is OnBuy slow because the 3PL on this lane is slow”.


What it counts	`% of OnBuy orders WHERE shipbob.shipment.tracked AND shipbob.shipment.dispatched_at <= onbuy.order.dispatch_due_by`. Numerator is on-time-dispatched ShipBob orders; denominator is total ShipBob-routed OnBuy orders.
Source data	OnBuy `GET /v2/orders` joined to ShipBob `GET /shipments` on `external_reference = onbuy_order_id` (the merchant configures this in ShipBob’s order-routing rules).
3PL scope	This card looks at ShipBob only. Other 3PLs (HuBox, Whistl, Bezos AI) get their own equivalents when those connectors are added; merchant-warehouse fulfilment is covered by `onbuy_sla_compliance`.
What “on-time” means	OnBuy’s `dispatch_due_by` field is the source of truth. ShipBob’s dispatch event must happen before that timestamp. Bank holiday adjustments are honoured per OnBuy’s calendar.
Refunds / cancellations	Cancelled orders are excluded from both numerator and denominator. Refunded orders count as on-time if dispatch happened on time, regardless of post-delivery refund.
Currency	Not relevant; this is an operational metric, not financial.
Time window	`30D`. Long enough to smooth daily ShipBob throughput variance; short enough to react to a 3PL issue before it becomes structural.
Alert trigger	`<90% on-time`. Below the 95% OnBuy SLA floor because 3PL handover adds 1 to 4h of latency vs in-house dispatch; the realistic ceiling for ShipBob-fulfilled OnBuy is 92 to 96%.
Roles	owner, operations.
Only when	`has_shipbob_sibling = true`. The card is hidden if the merchant does not run ShipBob.

Calculation

Calculated automatically from your OnBuy 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 small UK seller that uses ShipBob’s UK fulfilment centre (Pontefract) for OnBuy orders, rolling 30 days ending 27 Apr 26. The merchant routes all OnBuy orders to ShipBob; their own warehouse handles Shopify direct orders. The split lets ops measure 3PL performance independently of in-house fulfilment.

Channel	Total orders	On-time dispatch	SLA %
OnBuy via ShipBob (this card)	142	124	87.3%
OnBuy total (`onbuy_sla_compliance`)	142	124	87.3% (matches because ShipBob fulfils 100% of OnBuy)
Shopify direct (in-house warehouse)	280	274	97.9%

ShipBob OnBuy SLA  =  124 / 142  =  87.3%
In-house Shopify   =  274 / 280  =  97.9%
Gap                 =  10.6 percentage points

What it means for this seller. The ShipBob OnBuy line is 10.6 pp below the in-house Shopify line. That gap isolates the 3PL as the issue: same merchant, same SKUs, same product mix, fundamentally different dispatch performance. With OnBuy demanding 95% SLA, the merchant is below threshold and Boost eligibility is at risk. The breakdown of the 18 late ShipBob dispatches:

Cause	Count	Pattern
Pontefract pick-pack delay during Easter weekend	7	Cluster on 19 to 22 Apr 26, ShipBob ran skeleton crew
Late OnBuy order intake (sync delay > 2h)	4	Order pushed to ShipBob 4h after creation; due-by clock runs from OnBuy creation
Royal Mail collection missed at Pontefract	4	24 Apr 26, two consecutive days
Out-of-stock at ShipBob (in-stock at merchant)	3	Inventory sync drift between merchant warehouse and ShipBob

The action. Three concrete fixes available within 7 days. (1) Push back on ShipBob about Easter and bank-holiday dispatch cover; the contract should specify same-day dispatch on UK working days only, but skeleton-crew weekends are a contractual ambiguity that cost 7 of the 18 lates. (2) Move the OnBuy-to-ShipBob sync to webhook-triggered (currently a 30-min polling loop); recovers 4 to 6 lates per month. (3) Reconcile inventory between the merchant warehouse and ShipBob nightly; the 3 OOS-at-ShipBob orders represent revenue lost too. Combined fixes should lift the ShipBob OnBuy SLA from 87% to ~94 to 96%, back inside the OnBuy threshold. The same ShipBob fixes also benefit the merchant’s eBay UK orders if they ever route through ShipBob; the 3PL gap is symmetric across marketplaces.

Sibling cards merchants should reference together

This card isolates one half of the OnBuy fulfilment story (3PL); the natural pairings are with the other half (in-house) and the downstream consequences:

Card	Why it matters next to ShipBob SLA	What the combination tells you
Dispatch SLA Compliance (overall)	The all-orders SLA.	Compare this card to the overall, the gap is “how much is the 3PL dragging us down”.
Late Dispatch Count (30d)	The numerator behind the gap.	If most lates concentrate in ShipBob orders, the 3PL is the issue; if spread evenly, the warehouse is.
Late Dispatch Queue (alert)	Real-time list.	Use the per-order list to identify whether late orders carry ShipBob or in-house tracking numbers.
Pending Dispatch	Real-time backlog.	A spike in pending with predominantly ShipBob orders means an upstream sync or 3PL capacity break.
Avg Time to Dispatch (hrs)	Continuous-time view.	If avg dispatch hours rise on ShipBob orders specifically, the 3PL throughput slowed; if rising overall, multiple causes.
OnBuy Total Revenue	The downstream.	A 10pp ShipBob-SLA drop typically translates to a 5 to 15% revenue drop within 14 to 21 days as Boost de-listing kicks in.
Suspended Listings	Worst-case downstream.	Persistent <90% ShipBob SLA can lead to listing suspension; the cause-and-effect chain is short and visible.
ShipBob Open Shipments	The 3PL-side view.	The merchant should match ShipBob’s own dashboard against this card; gaps usually reveal sync issues.

Reconciling against the vendor’s own dashboard

Where to look in OnBuy’s own dashboard: OnBuy does not segment SLA by 3PL; this is a Vortex IQ-only view. The closest references are:

OnBuy Seller Console (https://seller.onbuy.com) -> Account Health -> Dispatch Performance (gives the all-orders SLA) ShipBob Dashboard (https://web.shipbob.com) -> Orders -> All Orders (filter by external_reference contains “ON-” to isolate OnBuy-routed orders)

The merchant must cross-reference manually, which most do not until OnBuy issues a Seller Score warning. Why our number may legitimately differ from a manual ShipBob-vs-OnBuy comparison:

Reason	Direction	Why
Tracking number match	Either	The OnBuy-to-ShipBob join uses `external_reference`. If the merchant’s order-routing rule does not pass the OnBuy order ID into the ShipBob shipment record, the matcher misses orders, deflating the denominator. Worth checking on first card load.
Time zone	Marginal	OnBuy uses Europe/London, ShipBob uses America/Chicago for its API timestamps. We normalise both to UTC. A boundary-of-day order could flip from on-time to late depending on the clock.
Bank holidays	Either	OnBuy adjusts `dispatch_due_by` for UK bank holidays automatically; ShipBob’s Pontefract centre also observes UK bank holidays; but ShipBob’s US centres do not. Cross-border ShipBob fulfilment (rare for OnBuy) can show timing surprises.
In-flight orders	Marginal	Orders not yet past `dispatch_due_by` are excluded from the calculation (we do not count an order as on-time until ShipBob confirms dispatch). Manual snapshots from ShipBob may show a different “open shipments” count.
Sync lag	Ours slightly lower for “today”	ShipBob webhook pushes are usually within 60 seconds, but a brief outage on the merchant’s webhook receiver can delay status updates by hours. The 30D figure is unaffected; “today” can be slightly under-counted.
3PL routing rule changes	Marginal	If the merchant changes which orders route to ShipBob mid-month (e.g. a category exclusion), the denominator shifts within the 30D window. The card uses orders-routed-at-time-of-creation, not retroactively re-routed.

Internal identity:

onbuy_xc_fulfilment_via_shipbob = COUNT(onbuy.order JOIN shipbob.shipment WHERE shipbob.dispatched_at <= onbuy.dispatch_due_by) / COUNT(onbuy.order JOIN shipbob.shipment)

The card is a strict subset of onbuy_sla_compliance: the difference between the two equals the contribution of non-ShipBob fulfilment to the overall SLA.

Known limitations / merchant FAQs

Why is the alert at 90% when OnBuy’s overall SLA threshold is 95%? 3PL handover adds 1 to 4 hours of latency vs in-house dispatch (the order has to be created in OnBuy, synced to ShipBob, picked, packed, scanned, and handed to the carrier). On a dispatch_due_by of 24 hours from order, that is 4 to 16% of the available window consumed before the warehouse even sees the pick ticket. The realistic ceiling for ShipBob-fulfilled OnBuy is 92 to 96%. Setting the alert at 90% accepts that gap as structural and only fires when something is genuinely wrong. My ShipBob SLA is 88% and my in-house SLA is 98%. Should I move OnBuy in-house? Often yes, but do the maths first. The cost trade-off is: ShipBob fee per order (~~£3 to £5 in the UK) vs the labour and pick-pack cost in-house (~~£1 to £3 if the warehouse is right-sized, more if it isn’t). If labour cost is similar but in-house SLA is materially higher, in-house wins on revenue alone, the SLA difference compounds into Boost eligibility and revenue lift. The exception is geographic: if you are based in London and ShipBob’s Pontefract centre serves the north faster than you can, regional split-routing may beat full in-housing. ShipBob and OnBuy show different dispatch times. Which is the source of truth? OnBuy is. OnBuy’s dispatched_at is the timestamp the carrier scan was uploaded to OnBuy, which is what counts for OnBuy SLA. ShipBob’s dispatched_at is the timestamp ShipBob handed the parcel to the carrier (often 30 to 90 minutes earlier, before the carrier scans it). For SLA purposes the OnBuy timestamp is binding. The ShipBob timestamp tells you whether the 3PL is meeting their internal SLA to you. My ShipBob orders are not appearing in this card. What’s wrong? Almost always a routing-rule misconfiguration. ShipBob’s order rule must pass external_reference = onbuy_order_id (or the merchant’s preferred field) so our matcher can join. Check ShipBob’s order-routing settings, look for the OnBuy integration in their Connections panel, and verify the external-reference mapping. If it is set correctly but matches still fail, raise a sync issue; the join logic is occasionally tripped by leading-zero formatting differences. Does this include international ShipBob fulfilment? ShipBob runs UK fulfilment from Pontefract; for OnBuy orders, this should be the only ShipBob centre involved (OnBuy is UK-only). If the merchant has set ShipBob to fall back to a US or EU centre when Pontefract is OOS, those orders will appear here but with much longer transit (3 to 7 days), almost guaranteeing late dispatch. Best practice: configure ShipBob with no cross-border fallback for OnBuy orders. Why is my ShipBob SLA worse than my Shopify direct SLA, even for the same SKUs? Two structural reasons. (1) OnBuy’s dispatch deadline is tighter than Shopify’s typical promise: OnBuy typically requires same-day dispatch on weekdays before cut-off, where Shopify direct often promises “1 to 2 working days” giving a wider window. (2) Sync latency: orders flow OnBuy -> Vortex IQ -> ShipBob, which adds 30 to 120 minutes of transmission time before the warehouse even knows about the order. Shopify-to-ShipBob is direct and faster. What is a healthy ShipBob OnBuy SLA? For a well-configured operation: 94 to 96%. Above 96% is rare without a dedicated cut-off-aligned fulfilment lane; below 92% is a structural issue that needs intervention. The OnBuy threshold itself is 95%, so 94 to 96% is comfortably bracketing it. My SLA dropped because of a single ShipBob outage. Will it recover? Yes. The 30D rolling window means a single bad day takes ~7 to 10 days to wash out of the average. ShipBob outages are rare but typically resolve within 24 hours; recovery on this card lags by the rolling-window length, not the outage duration.

Tracked live in Vortex IQ Nerve Centre

OnBuy Orders via ShipBob (SLA) is one of hundreds of KPI pulses Vortex IQ tracks across OnBuy 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 or book a demo to see this metric running on your own data.

Get Started

The AI OS

OnBuy Orders via ShipBob (SLA), OnBuy

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre

​At a glance

​Calculation

​Worked example

​Sibling cards merchants should reference together

​Reconciling against the vendor’s own dashboard

​Known limitations / merchant FAQs

​Tracked live in Vortex IQ Nerve Centre

At a glance

Calculation

Worked example

Sibling cards merchants should reference together

Reconciling against the vendor’s own dashboard

Known limitations / merchant FAQs

Tracked live in Vortex IQ Nerve Centre