At a glance
Number of paid orders awaiting fulfilment. Growing backlog means an operational bottleneck, customers expect 1-2 day processing, and every day an order sits unfulfilled is a day closer to a customer service ticket, a chargeback, or a negative review. The card answers the operational question every fulfilment manager asks at the start of every shift: how big is the queue right now, and is it growing or shrinking?
| What it counts | The count of orders with payment_status IN ('paid', 'captured') and fulfillment_status IN ('unfulfilled', 'partial') at the time of the most recent ingestion. Excludes refunded, cancelled, and fully-fulfilled orders. |
| Sample type | Backend API data from BigCommerce orders, refreshed on the standard data refresh. |
| Why unfulfilled count matters | (1) Customer experience: customers expect dispatch within 1-2 business days; orders past that threshold trigger anxiety and contact-centre tickets. (2) Cash flow: paid-but-unfulfilled orders represent revenue you cannot recognise, returns you cannot prevent, and inventory you cannot redeploy. (3) Reputation: late fulfilment drives 1-star reviews, refund requests, and chargebacks, each of which compounds into long-term damage. (4) Operational signal: a growing backlog means the merchant is fulfilling slower than they’re selling, an unsustainable trajectory. |
| Reading the value | (1) Below 10: lean operations; backlog under control. (2) 10-50: typical operational state for any non-trivial volume; address oldest first. (3) Above 50: alert state; either a fulfilment-process bottleneck, supplier delay, OOS preventing dispatch, or a sudden demand surge unmatched by capacity. (4) Compare to daily order volume, backlog should not exceed 1-2 days of intake. |
| Currency | absolute count. |
| Time window | snapshot. |
| Alert trigger | unfulfilled_count > 10 (BAD threshold at 50). |
| Sentiment key | unfulfilled_count (LOWER_IS_BETTER in SentimentClassifier; GOOD ≤ 10, BAD ≥ 50). |
| Roles | owner, operations, customer_service |
Calculation
Worked example
A UK-based BigCommerce home-and-garden store, unfulfilled orders reading on Wednesday 15 May 26.| Metric | Value | Status |
|---|---|---|
| Total open orders (paid, awaiting fulfilment) | 224 | - |
| Daily order intake (90D average) | 70 | - |
| Backlog days | 3.2 days | Above target |
| Oldest unfulfilled order age | 9 days | Critical |
| Orders waiting on OOS items | 47 | Cross-reference out_of_stock_count |
| Orders ready to ship (in stock) | 177 | Operational queue |
- The backlog is 3.2 days of intake. With 70 orders per day inbound and 224 unfulfilled, the queue would take 3.2 days to clear if no new orders arrived. Operational target is 1-2 days; 3.2 days means the team is fulfilling slower than the demand.
-
Decompose the queue:
- 47 orders are blocked on OOS items: these cannot be fulfilled until the inventory arrives or the customer is offered a substitute. Cross-reference
out_of_stock_count. - 177 orders are ready to ship: these are the actionable backlog. At a healthy fulfilment rate of 80 orders/day, this is 2.2 days of work for the team, borderline manageable but not lean.
- The oldest order is 9 days old: every day past the 1-2 day expectation increases the probability of a customer-service contact, a refund request, or a chargeback.
- 47 orders are blocked on OOS items: these cannot be fulfilled until the inventory arrives or the customer is offered a substitute. Cross-reference
-
Why the backlog grew:
- Demand surge: order intake may have spiked above the team’s daily fulfilment capacity (check against 30D rolling intake).
- Capacity issue: a fulfilment-team absence, warehouse incident, or supplier delivery delay reduced output.
- Process bottleneck: a new packaging requirement, address-validation step, or shipping-carrier issue is slowing per-order processing.
- OOS pile-up: blocked-on-stock orders accumulating because new stock hasn’t arrived.
-
Recommended response, in priority order:
- Hour 1: Identify the 9-day-old order and any others above 5 days. Personally email each customer with status + estimated dispatch + apology. Pre-empt the contact-centre ticket and the negative review.
- Day 1: Sort the 177 ready-to-ship by order age (oldest first); fulfil oldest first to drain the long-tail risk.
- Day 1-2: For the 47 OOS-blocked orders, contact each customer with options: (a) wait for restock, (b) substitute, (c) refund.
- Day 2-3: Identify the bottleneck (capacity, process, supplier) and apply specific fix.
- Day 7: Confirm backlog reduced to 1-2 days of intake.
- Result: customer-service ticket volume normalises within 48 hours of clearing the long-tail; refund/chargeback risk closes; backlog returns to operational target.
-
The chargeback prevention angle. Orders unfulfilled past 7-10 days frequently trigger:
- Customer-service refund requests (which the merchant must absorb plus shipping cost).
- Card-issuer chargebacks (which damage the merchant’s processor reputation, increase processing costs, and risk MID restrictions).
- Personal email outreach within 48 hours of order placement dramatically reduces both. The cost is one customer-service interaction per delayed order; the saving is the chargeback fee plus refund operational cost plus reputation cost.
-
Cross-reference cards:
fulfillment_rate: percentage of orders fulfilled (compare to backlog count).out_of_stock_count: identifies the OOS-blocked subset of the backlog.bc_aov_by_country: high-AOV orders should be fulfilled first to minimise refund exposure.bc_alert_fulfilment_delay: explicit alert when the backlog exceeds the threshold.
- Read the count. Above 50 triggers alert; above 100 is severe.
- Decompose: ready-to-ship vs OOS-blocked vs old-tail.
- Personally outreach the old-tail to prevent escalation.
- Clear ready-to-ship oldest-first.
- Identify and fix the bottleneck (capacity, process, supplier).
- Re-audit daily until backlog returns to target.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify oldest orders. Email customers. |
| First day | Sort by age, fulfil oldest first. Contact OOS-blocked customers. |
| First week | Backlog reduced to 1-2 days. |
| Day 14 | Bottleneck identified and fixed. |
| Ongoing | Daily backlog check; pre-emptive outreach for any order > 3 days. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
fulfillment_rate | Fulfilment % over time; complements the absolute backlog count. |
out_of_stock_count | OOS-blocked subset of the backlog. |
cancellation_rate | Backlog-driven cancellations show up here. |
refund_rate | Backlog-driven refunds show up here. |
bc_alert_fulfilment_delay | Explicit alert when backlog crosses threshold. |
order_count_trend | Demand intake; backlog grows when intake exceeds capacity. |
Reconciling against the vendor’s own dashboard
Where to look in BC: Orders → Filter by status “Awaiting Fulfilment” or “Awaiting Shipment”; Orders → Reports → Aging report. Why our number may differ:| Reason | Direction | What to do |
|---|---|---|
| Status interpretation. BC has multiple “open” states (awaiting fulfilment, awaiting shipment, partially shipped); Vortex IQ aggregates the operational subset. | Variable | Confirm which states are included. |
| Pre-order treatment. Pre-orders awaiting stock count differently. | BC may differ | Confirm pre-order policy. |
| Manual orders. Some merchants exclude manual orders from the operational queue. | Variable | Match profile filter. |
shipbob.sb_health_score if 3PL fulfilment is in use.
Quick rule: confirm status-state inclusion and pre-order policy first.
Known limitations / merchant FAQs
Q: We have 224 unfulfilled orders but they’re all from yesterday. Is that an alert? Depends on your daily intake. If you receive 200 orders per day, 224 unfulfilled is one day of backlog, operationally fine. If you receive 70 per day, 224 is 3.2 days of backlog and is a problem. The metric should be read against intake: backlog should not exceed 1-2 days of intake. Q: Should pre-orders count as unfulfilled? Configurable per profile. Pre-orders are intentional delays, the customer chose a future ship date. They should not contribute to operational urgency. Exclude pre-orders from this card; track them separately on a dedicated pre-order monitoring card. Q: Our oldest order is 12 days old. Is that already a chargeback? Possibly. Card schemes typically allow chargebacks once the cardholder reasonably believes the merchandise won’t arrive. For an order placed 12 days ago without dispatch, the cardholder may already be filing a dispute. Personal outreach immediately is the cheapest mitigation; offering an immediate refund + free reship if/when stock arrives is the second-best option. Q: We use a 3PL. Are 3PL-side delays counted here? Yes, the card is platform-agnostic to where the delay originates. If the 3PL hasn’t fulfilled the order yet, BC’s status remains “awaiting fulfilment” and the order counts. Cross-referenceshipbob.sb_health_score (or equivalent 3PL card) to identify whether the bottleneck is at the 3PL.
Q: Backlog spikes during BFCM. Should we widen the threshold?
Many merchants do. For peak weeks, BAD threshold can be raised to 200 or 500 depending on volume; the alert is still useful (tells you when to add temporary capacity) but doesn’t fire continuously through the peak.
Q: We had a customer cancel an order that was already in fulfilment. How does that flow?
If the order was cancelled before dispatch, fulfillment_status moves to cancelled and it stops contributing to this count. If it was already in transit, it remains “shipped” and exits this card; the cancellation becomes a refund/return event tracked separately.
Q: Why doesn’t this card include pending-payment orders?
Because pending-payment orders aren’t yet committed orders, they’re abandoned-payment carts that may never complete. Counting them inflates the operational queue with non-actionable items. Pending-payment orders are tracked separately as cart-abandonment / failed-orders signals.
Q: How does this card differ from fulfillment_rate?
fulfillment_rate is a percentage (orders fulfilled / total orders) over time. This card is the absolute count of currently-open orders. Use the rate for the trend; use the count for the operational shift-by-shift queue management.