How to calculate the cost of a stockout (and why so many are silent)

A stockout looks free. There's no refund, no chargeback, no angry email in the moment — the customer just hits an "out of stock" button and leaves. Nothing hits your P&L with a red number. That's exactly why out-of-stocks are one of the most under-counted leaks in a DTC business: the cost is a sale that never happened, and you can't see the thing that didn't occur.

But you *can* estimate it, and the estimate is usually bigger than operators expect.

The formula

Start with the demand that hit an empty shelf:

Lost units = units sold per day (in stock) × days out of stock × SKUs affected

If a SKU sells 8 units a day when it's available, and it's out of stock 20 days a year, that's 160 units of demand you couldn't serve on that one SKU. Across 5 SKUs with a similar pattern, it's 800 units a year.

Turn that into money at your selling price:

Demand at risk = lost units × price

At $45 a unit, 800 units is $36,000 of demand that arrived and found nothing to buy.

Not all of it is lost — but most of it usually is

Here's the part that makes stockouts easy to under-count *or* over-count. Some of that demand comes back: the customer backorders, buys a substitute from you, or returns later. The rest is gone — they bought from a competitor, or the impulse passed.

Revenue lost for good = demand at risk × (1 − recapture rate)

The recapture rate is a judgement call, and it's where honesty matters. Most published retail studies suggest the *majority* of stockout demand is not recovered — shoppers substitute at another store more often than they wait. If you recapture 30% and lose 70%, that $36,000 of demand at risk becomes $25,200 of revenue lost for good.

And revenue isn't the number that hurts most — gross profit is. At a 55% gross margin, that permanent revenue loss is ~$13,860 of gross profit you never booked, on just five SKUs. (Run your own numbers in the Stockout Cost Calculator — every figure here is illustrative and comes straight from the inputs.)

Why so many stockouts are a data problem, not a demand problem

The instinctive read on a stockout is "we sold out faster than we forecast." Sometimes that's true. But a large share of out-of-stocks in a multi-system DTC stack aren't a forecasting miss at all — they're *silent failures* in the plumbing between Shopify, your 3PL, and your ops:

• Phantom availability — Shopify shows stock that the 3PL doesn't actually have, so orders come in that you then have to cancel, and the SKU sits "sellable" while effectively dead.
• Inventory drift and oversell — counts diverge across systems until a launch or promo zeroes you out and starts cancelling orders.
• Reorder signals that never fired — you rely on a low-stock trigger to reorder, but a stale sync means the trigger quietly stopped, and nobody notices until the shelf is empty.
• Stuck receiving — inbound stock landed at the warehouse but never posted to "available," so you're marked out of stock while the units are physically sitting there.

These don't announce themselves. There's no alert when a sync stops — that's the whole problem. You find out days later, from a cancelled order or a customer who went elsewhere.

The takeaway

Two things are true at once: the cost of a stockout is real and usually larger than it feels, *and* a meaningful chunk of stockouts are preventable data problems rather than genuine demand you couldn't have met. Size the first with a simple estimate. Attack the second by making the silent failures visible.

That second part is what Ops Monitor does: it connects to Shopify and Stripe with read-only keys and watches for inventory diverging across systems, syncs that quietly stopped, and orders stuck past SLA — then alerts you before a phantom stockout turns into a wall of cancelled orders. It detects and alerts; it doesn't prevent stockouts or guarantee anything. But catching one broken sync before a big promo often protects far more than it costs.