E-commerce
July 3, 2026
"It was marked as in stock, I paid, and you cancel on me two days later." "Google Shopping showed it was available, your site says out of stock." "I added it to the cart while there was one unit left, checkout declined." These are not classic out-of-stock questions: they are stock display errors, where the visible promise does not match the actual inventory.
Skulabs estimates that about 34% of e-commerce retailers reported inventory discrepancies leading to overselling in 2024, with an operational cost of 25 to 75 dollars per oversold order (Skulabs, cost of overselling 2025). Embed360 recommends contacting the customer within two hours of discovering the overselling, before they discover the cancellation on their own (Embed360, overselling 2026).
This guide #319 covers support for displayed stock errors: preventing, explaining, compensating. It complements general out-of-stock (#106) from the angle of overselling, sync lag and compensation matrix, distinct from the stock incidents bot (#320).
Summary
Why is a stock display error more serious than an announced out-of-stock?
An out-of-stock notice on the product page creates disappointment. A display error creates perceived betrayal: the customer acted on false information, often after payment.
Three differences vs transparent out-of-stock
Broken promise: "in stock" displayed, order canceled afterwards
Merchant responsibility: the customer did not ignore an out-of-stock badge
Chargeback risk: poorly explained cancellation = card dispute
Real cost of an incident
US Tech Automations estimates an oversell at between 65 and 120 dollars per event, including reimbursement, reverse logistics, and customer service time (US Tech, oversell 2026). StockPilot estimates 15 to 50 dollars in direct costs plus 100 to 300 dollars in lost customer lifetime value on Shopify (StockPilot, overselling Shopify 2026). PwC via Skulabs: 32% of customers stop buying after a single poor fulfillment experience.
Principle #319
STOCK-DISP-LOOP Pipeline: prevent display → detect discrepancy → recover customer (STOCK-DISP-RECOVER) → compensate (STOCK-COMP) → post-mortem ops.
How does it differ from out of stock #106, restocking #167, and bot #320?
Four related contents, four stock perspectives.
General Out of Stock (#106)
Out of Stock (#106): alternatives, alerts, honest OOS scripts. Issue #319: overselling and display vs. actual discrepancy, with reinforced compensation protocol.
Restocking Delays (#167)
Restocking (#167): ETA and customer waiting time. Issue #319: incident where displayed stock was incorrect, not just a simple delay.
OOS Alternatives Bot
OOS Alternatives Bot: pre-purchase recommendation. Issue #319: post-order oversold and multi-channel sync.
Incident Bot (#320)
Issue #319 establishes customer service policy, macros and compensation matrix; see incident bot (#320) for automated execution.
Sales (#318)
Sales (#318): promo peak. Issue #319: root cause sync and display, amplified during flash sales.
Promise #319
STOCK-DISP-INTENT, STOCK-DISP-PREVENT, STOCK-DISP-RECOVER, STOCK-COMP, STOCK-ROOT, macros, handoff ops, KPI oversell.
What STOCK-DISP-INTENT taxonomy should be used to classify the tickets?
The STOCK-DISP-INTENT taxonomy distinguishes display errors from simple availability questions.
10 stock error intents
disp_oversell_postpay: order paid, cancellation due to insufficient stockdisp_checkout_block: cart lost between display and paymentdisp_pdp_mismatch: "in stock" on PDP vs out of stock at checkoutdisp_marketplace_lag: Google Shopping / Meta vs websitedisp_multichannel: sold on Amazon + website, same stock pooldisp_partial_fulfill: partial order, missing itemdisp_preorder_confusion: customer believed stock was immediatedisp_qty_wrong: "Only 2 left" when there are 0 in the warehousedisp_dropship_lag: supplier OOS, website still opendisp_compensation_claim: request for commercial gesture after incident
CS Prioritization
P1: disp_oversell_postpay and unshipped disp_partial_fulfill. P2: disp_checkout_block active customer. P3: pre-purchase disp_marketplace_lag. Tag stock_display_error separated from stockout_general (#106) for analytics and post-mortem.
How can display errors be prevented with STOCK-DISP-PREVENT?
The STOCK-DISP-PREVENT protocol reduces incidents before they reach customer service.
8 Shopify DTC measures
Track quantity enabled on 100% of sellable SKUs
Continue selling when out of stock disabled except for documented pre-orders
Safety buffer: display max (actual stock - N), e.g., N=2 or 10% (Dropioneer, buffer 2026)
Multi-channel sync: inventory push < 60 s between channels (US Tech 2026)
Negative stock alert: webhook if qty < 0, P1 customer service queue
Reconciliation job: compare projection vs Shopify every 10 min during peak (72Technologies, sync 2026)
Google/Meta Feed: pause OOS SKUs, no 24 h delay
Staging test: oversell scenario before BFCM or drop
Preventive UX
"Limited stock" badge if qty < 5. 15-minute cart reservation countdown. Checkout message if qty changes between cart and payment. See back-in-stock alerts.
How do I run STOCK-DISP-RECOVER when overselling is detected?
The STOCK-DISP-RECOVER protocol structures the after-sales response within 2 hours after ops detection.
7 recover steps
Freeze SKU: qty at 0 on all channels, pause SKU ads
List impacted orders: export Shopify unfulfilled + negative qty
Contact customer before auto-cancellation: email + SMS if phone, Embed360 2-hour rule
Offer 4 options: wait for restock (firm ETA), swap, partial cancellation, total cancellation (Casekit, OOS cancellation 2026)
Execute customer's choice: immediate refund if cancelled, no investigation blocking
Apply STOCK-COMP section 6 if policy provides for it
Log incident: SKU, cause, resolution, cost, ticket ID → post-mortem ops
Recover Prohibitions
Silent cancellation without email. Vague "soon" backorder without a date. Blaming the customer ("you should have ordered faster"). Withholding refund during internal investigation.
Partial order
Casekit recommends split ship: ship available items, offer swap or refund for OOS item (Casekit, backorder 2026). Macro variables: {order_ref}, {items_oos}, {refund_timeline}, {swap_options}.
Which STOCK-COMP matrix should be used to compensate without over-allocating?
The STOCK-COMP matrix standardizes commercial gestures based on severity and customer value.
4-level grid
N1 Pre-purchase discrepancy (PDP/checkout, no payment): apologies + stock alert link or alternative. Gesture: optional single-use -5% code.
N2 Resolved swap oversell: customer accepts equivalent alternative. Gesture: free express delivery or -10% off next order.
N3 Post-payment cancellation: full refund + gesture. Gesture: -15% code or 10% partial refund if waiting is refused (Dropioneer retention pattern).
N4 Repeated or VIP: 2nd incident within 12 months or customer LTV > threshold. Gesture: refund + -20% code + manager escalation + account note.
Agent caps
STOCK-COMP-POLICY document: max amount without manager approval (e.g., €25 or 15% of order). Beyond: team lead validation. Never promise unbudgeted compensation in macro bot.
What does not qualify for compensation
Customer error (wrong variant chosen while stock was correct). Stockout clearly announced before purchase. Pre-order with displayed and respected lead time.
Numerical example
Order €89, size M oversell, cancellation. €89 refund within 48h + SORRY15 code (-15%, 30 days). Direct cost ~€12 code margin + 8 min customer service. Avoided cost: chargeback ~€89 + 1-star review.
Which STOCK-DISP macros should be used depending on the intent?
The STOCK-DISP macros guarantee an empathetic tone and clear options. Prefix DISP- in the helpdesk.
6 essential macros
DISP-OVERSOLD: "We have noticed a stock discrepancy on {sku}. Your order {order_ref} is affected. Here are your options: A) restocking {eta} B) alternative {swap} C) full refund within {refund_timeline}."
DISP-CHECKOUT: "Stock levels changed during your session. {variant_alt} is still available, or set up a return alert: {link}."
DISP-MARKETPLACE: "Our Google feed may show a 4-6 hour update delay. Real-time site stock: {status}."
DISP-PARTIAL: "We are shipping {items_ok} today. For {item_oos}: swap or partial refund {amount}."
DISP-COMP: "As a commercial gesture for this incident: {geste}. Code: {code}."
DISP-ROOT-ACK: "We have corrected the root cause ({sync/canaux}) to prevent recurrence."
Writing rules
ChannelEngine: acknowledge the error without WMS jargon (ChannelEngine, trust 2026). Factual, numbered options, explicit refund timeline (3-5 business days). Link to support templates (#34), order modification.
How to trace the root cause with STOCK-ROOT and handoff ops?
Each stock_display_error ticket feeds into an ops STOCK-ROOT post-mortem, not just a refund.
6 typical root causes
root_sync_lag: WMS/3PL API latency > 15 minroot_multichannel_race: two channels, same unitroot_continue_selling: Shopify setting misconfiguredroot_manual_override: qty edited in admin without syncroot_feed_stale: Google/Meta feed not refreshedroot_dropship_unreliable: supplier OOS, site open
Notion incident report
Fields: date, SKU, displayed vs actual qty, impacted orders, root cause, ops fix, total STOCK-COMP cost, owner, closed status. Weekly review if > 2 incidents/week.
Support → ops handoff
Agent does not modify inventory without an ops ticket. Slack #stock-incidents: 5-line template (SKU, order IDs, customer verbatim, PDP screenshot if relevant). Ops confirms fix + DISP-ROOT-ACK response within 24 hours.
Sales and drops link
Flash sales and influencers amplify root_multichannel_race. See sales (#318), dropshipping (#96), ticket prioritization (#26).
Which vertical playbooks for fashion, beauty, and marketplace?
Displayed stock incidents vary by catalog and channel.
Fashion / footwear
Peak disp_checkout_block on remaining one-size-fit. Size/color swap is priority. Buffer per variant, not per parent product. STOCK-COMP N2 grid favored (customer wants the model).
Beauty / limited drops
Frequent flash oversellers. Freeze SKU + Instagram story communication if ticket volume is high. No backorder without a firm supplier date. Product launch link.
Multi-channel Amazon + DTC
root_multichannel_race dominant. OMS orchestration mandatory. Macro DISP-MARKETPLACE is insufficient: explain inter-platform sync delay. US Tech: push-down qty=0 all channels in < 60 s.
Dropshipping
root_dropship_unreliable. Policy: never display raw supplier qty. Sync delay 4 h max or hide SKU. See dropshipping (#96).
B2B / wholesale
MOQ and reservations: display error = account manager escalation, not DTC macro. Reserved stock vs available for sale: two distinct inventory fields.
Which KPIs should be measured for displayed stock errors?
Measure incidents and recovery, not raw stockout volume (#106).
Monthly KPIs
oversell_rate: stock-cancelled orders / total orders
disp_ticket_rate: stock_display_error tickets / orders
recover_contact_sla: % of customers contacted < 2 hours post-detection
recover_save_rate: swap or wait vs total refund
stock_comp_cost: total amount of STOCK-COMP
repeat_disp_12m: customers with 2+ incidents (churn alert)
root_recurrence: same root cause 2×/month = ops fix required
chargeback_disp: disputes related to stock cancellation
Typical DTC Goals
oversell_rate < 0.3% of orders. recover_contact_sla > 95%. recover_save_rate > 25% (swap or wait). stock_comp_cost < 2% of monthly margin. Loopwork reports 79% of customers do not return after a poor stock experience (Loopwork, sync 2026).
How does Qstomy handle instore/out-of-stock incidents shown in conversations?
Qstomy runs STOCK-DISP-RECOVER in chat: intent detection, swap/refund options, Shopify order sync, capped STOCK-COMP application.
Capabilities
Intent
disp_oversell_postpaywith Casekit 4-option treeReal-time reading of order status + unfulfilled items
Recommendation of alternative SKUs from the same collection (live stock)
STOCK-COMP code application according to the N1-N4 matrix
P1 escalation if negative qty detected via webhook
Export of STOCK-ROOT incidents to Notion ops
Quantified DTC Scenario
Accessories brand, 6,800 orders/month, multi-channel sync. Before #319: 14 oversells/month, average customer contact 18 hours post-cancellation, recover_save_rate 8%, 3 chargebacks per quarter. After STOCK-DISP-RECOVER + Qstomy: oversells 9/month (buffer + reconciliation), contact < 1 h (webhook + proactive bot), recover_save_rate 31%, chargebacks 0, stock_comp_cost €420/month vs estimated avoided chargeback cost of €1,800.
See AI support, sales agent, Shopify, demo. Dedicated guide: stock incident bot (#320).
Which playbooks should be used to deploy STOCK-DISP-LOOP in four weeks?
Playbook 1: display audit (4 h)
SKU Export: track qty, continue selling, buffer. Scan Google feed. List 90 days of stock_display_error tickets or stock cancellations.
Playbook 2: STOCK-DISP-PREVENT (1 d)
Apply 8 measures from section 4. Configure negative qty alert. Test staging oversell.
Playbook 3: policy + macros (4 h)
Draft STOCK-COMP-POLICY + 6 DISP-* macros. Train team on the 4 options tree.
Playbook 4: recover runbook (2 h)
7-step STOCK-DISP-RECOVER document. Slack channel #stock-incidents. Owner ops + support.
Playbook 5: monthly review (60 min)
KPI section 10. Post-mortem root_recurrence. Adjust buffer and COMP caps.
Useful links
This week: tag your stock cancellations from the last 30 days with disp_oversell_postpay and measure the average time between Shopify cancellation and first customer contact. If this time exceeds 2 h, STOCK-DISP-RECOVER is not yet in place.
Enzo
July 3, 2026
