At a glance
Number of active products approaching out-of-stock based on current inventory and burn rate. The leading indicator that prevents OOS events. Each product flagged here can still be reordered before it stocks out; once it crosses to zero (out_of_stock_count), the revenue is already foregone. The card surfaces the products at risk so reorders can be placed proactively rather than reactively.
| What it counts | The count of active products where inventory_level <= low_stock_threshold AND inventory_level > 0. The threshold is per-product, configurable in BC (default ~5 units), and represents the merchant’s reorder trigger. Excludes products already at zero (those are tracked by out_of_stock_count). |
| Sample type | Backend API data from BigCommerce inventory, refreshed on the standard data refresh. |
| Why low stock matters | (1) Prevents OOS: every product caught at low-stock and reordered is a product that does not become OOS later. (2) Inventory-planning signal: a growing low-stock count means the merchant is selling faster than reordering, an unsustainable trajectory. (3) Bestseller protection: high-revenue products at low stock are the urgent reorder list; long-tail at low stock can wait. (4) Cash-flow signal: low-stock reorder demand competes with other capital uses; the count plus per-SKU reorder cost gives total reorder spend forecast. |
| Reading the value | (1) 0-5: lean inventory operations, all reorders being placed proactively. (2) 5-20: typical operational state; address bestsellers as they appear. (3) Above 20: alert state; reorder cadence is lagging sales velocity. (4) Cross-reference out_of_stock_count (downstream effect) and bc_revenue_by_brand (revenue exposure of low-stock items). |
| Currency | absolute count. |
| Time window | snapshot. |
| Alert trigger | bc_low_stock > 20 (configurable per merchant; small catalogues may use 5). |
| Sentiment key | bc_low_stock (LOWER_IS_BETTER). |
| Roles | owner, operations, merchandising |
Calculation
low_stock_threshold is per-product, set in BC’s product editor. Default is typically 5 units; merchants may set higher thresholds for high-velocity SKUs.
Worked example
A UK-based BigCommerce home-and-garden store, low stock reading on Wednesday 15 May 26.| Tier | Count | Revenue exposure | Reorder cost estimate | Days to OOS at current burn |
|---|---|---|---|---|
| Top 100 by 90D revenue (bestsellers) | 8 | £18,400/week | £6,200 | 4-6 days |
| Top 1,000 by 90D revenue | 24 | £42,800/week | £19,400 | 5-9 days |
| Long tail (rest) | 142 | £4,200/week | £36,800 | 12-30 days |
| Total low stock | 174 | £65,400/week | £62,400 | - |
- Bestseller tier is the urgent action: 8 products at risk of OOS within 4-6 days. At a combined revenue exposure of £18,400/week, an OOS event on these 8 products costs £18K/week × 7-21 days reorder lead time = £18K-55K of foregone revenue per week of delay.
- Reorder priority by revenue exposure, not by count. The 8 bestsellers represent £18,400/week vs the long tail’s £4,200/week. Same urgency action on a long-tail item produces 4x less revenue protection than the same action on a bestseller.
- The reorder spend forecast. Total estimated reorder cost £62K. Cross-reference cash position. A merchant with £62K of liquid working capital tied up in this reorder cycle is at the limit; one with significantly more headroom can reorder proactively without strain.
-
Days-to-OOS gives the urgency window:
- Bestsellers: 4-6 days. Order today; supplier lead times of 7+ days will result in OOS.
- Top-1K tier: 5-9 days. Order this week.
- Long tail: 12-30 days. Order in the next reorder cycle (no urgency).
-
Recommended response, in priority order:
- Hour 1: Place reorder for the 8 bestsellers. Confirm supplier lead time and expedite if possible.
- Day 1: For bestsellers with supplier lead time exceeding the days-to-OOS window, consider: (a) sourcing from secondary supplier, (b) pulling ad spend off these PDPs to slow burn, (c) raising price to slow burn while maintaining revenue.
- Day 2-3: Reorder top-1K tier in the standard reorder workflow.
- Day 7: Re-audit; the count should drop as reorders arrive.
- Ongoing: Review the per-product
low_stock_thresholdsettings, if bestsellers are flagging at the same threshold as long-tail (default 5), set higher thresholds for bestsellers (e.g., 20) to give earlier warning.
-
Cross-reference cards:
out_of_stock_count(downstream): products that already crossed to zero.bc_revenue_by_brand(revenue context): brand-level reorder priority.bc_xc_ads_on_oos(ad waste): also catches ads pointing at low-stock products at risk of OOS.bc_alert_oos_spike(alert): explicit OOS event detection.
- Read the count. Above 20 triggers attention.
- Stratify by revenue exposure (bestseller, top-1K, long tail).
- Reorder bestsellers immediately; long tail can wait for the next cycle.
- Cross-reference reorder cost against working capital.
- Adjust
low_stock_thresholdfor bestsellers to raise the early warning.
| Time horizon | Action |
|---|---|
| First 1 hour | Identify bestseller subset. Place reorders. |
| First day | Reorder top-1K tier. |
| First week | Long-tail reorder cycle. |
| Day 14 | Re-audit; tune per-product thresholds. |
Sibling cards merchants should reference together
| Card | Why merchants reach for it |
|---|---|
out_of_stock_count | Downstream effect; products already OOS. |
bc_inventory_dist | Inventory distribution across catalogue. |
bc_revenue_by_brand | Revenue exposure by brand. |
bc_revenue_by_category | Revenue exposure by category. |
bc_xc_ads_on_oos | Ad spend at risk on low-stock items. |
bc_alert_oos_spike | Explicit OOS event alert. |
Reconciling against the vendor’s own dashboard
Where to look in BC: Products → Filter by inventory ≤ low_stock_threshold; Inventory → Stock Levels report. Why our number may differ:| Reason | Direction | What to do |
|---|---|---|
| Threshold inheritance. BC may use a global default threshold for products without a per-product setting; Vortex IQ matches this behaviour. | Match | Confirm setting. |
| Variant-level inventory. A product with 5 variants where 1 is low-stock may or may not appear depending on aggregation policy. | Variable | Confirm aggregation rule. |
| Inventory tracking off. Excluded by both BC and Vortex IQ. | Match | n/a. |
shopify.low_stock, adobe_commerce.low_stock for cross-platform parity.
Quick rule: confirm threshold inheritance and variant-level aggregation policy first.
Known limitations / merchant FAQs
Q: How is “low stock threshold” defined? Per-product, set in BC’s product editor (low_stock_warning_quantity field). Default is typically 5 units. Merchants should set higher thresholds for high-velocity SKUs (e.g., 20-50 for bestsellers) to get earlier warning aligned with supplier lead times.
Q: Can I set thresholds based on burn rate rather than absolute count?
Not natively in BC. Vortex IQ can compute a velocity-aware threshold (e.g., flag any product with less than 7 days’ inventory at current burn) via Vortex Mind. The native card uses BC’s static threshold.
Q: We have 174 low stock items. Can’t reorder all at once. Where do I start?
By revenue exposure. The top 100 by 90D revenue is your urgent action list; everything else can wait for the next reorder cycle. Use bc_revenue_by_brand and bc_revenue_by_category to prioritise within the bestseller tier.
Q: Should I raise prices on low-stock bestsellers to slow burn?
Sometimes, temporarily. If supplier lead time exceeds the days-to-OOS window, a 10-15% price increase (or pulling ad spend) buys time without permanently losing demand. Most stores pull ad spend before raising prices because the latter risks brand impressions; ad pause is reversible and invisible to existing customers.
Q: Variant-level low stock, when does the parent product appear?
Configurable. Default behaviour: a product appears in this card when at least one of its variants is at or below low_stock_threshold AND at least one variant has positive inventory. Adjust per-profile if your business prefers stricter (all variants low) or looser (any variant low) logic.
Q: We use a 3PL with separate stock tracking. Are 3PL inventory levels reflected here?
Only if the 3PL syncs inventory back to BC (typical setup). If your 3PL uses its own inventory of record and doesn’t sync to BC, this card will show BC’s stale numbers. Verify the sync integration is working; cross-reference 3PL-specific inventory cards if available.
Q: Why do products that just shipped still show as low-stock for a few minutes?
Inventory updates propagate through BC’s API on a delay (typically 30-60 seconds for storefront, longer for backend reads). The card reads on the standard data refresh (typically 30-60 minutes), so very recent inventory changes may take one cycle to reflect. Force a manual refresh if needed.
Q: How does this card differ from out_of_stock_count?
This card is the leading indicator (products approaching OOS). out_of_stock_count is the trailing indicator (products already OOS). Use this card to prevent OOS; use the OOS card to remediate after the fact.