Shopify retail stockouts that erase their own demand

Store 4 sold nine of the hero hoodie in medium over the last 30 days. The weekly review divides nine by thirty, gets 0.3 a day, sees six on the shelf, and calls it 20 days of cover — healthy, no transfer. What the review cannot see from the sales number is that the shelf was empty from day 8 to day 26. The nine units sold in twelve days, not thirty. The store sells 0.75 a day when it has the product, six units is eight days of cover, and the door that looked healthiest in the report is the one that will be out again by next Tuesday.

This post does one job: fix the velocity you size retail-door replenishment from, because a stockout at a POS location deletes the evidence of its own demand in a way an online stockout does not. It is not the post about which sales window to trust in a promo week (velocity windows) or about online orders whose location is a routing outcome (routing vs transfers). Both of those assume the sale happened somewhere. This is about the sale that did not.

A POS stockout leaves no trace an online one leaves

When the West 3PL is out of a SKU, the West Coast customer still gets it — routing falls through to the East hub, the order exists, and the ship-to state tells you where the demand was. You can rebuild the 3PL’s real demand from those orders any time you like. When Store 4 is out, the customer who came in for it walks out. There is no order, no line, no address. Shopify recorded nothing because nothing happened, and every per-location report from that day forward is accurate about sales and silent about demand.

That silence has a shape. A retail door’s recorded velocity is true demand multiplied by the fraction of the window it was in stock. A door that was out for 60% of the month reads at 40% of its real rate, and the report gives no hint anything is missing, because the number is a real count of real sales. You cannot spot the error by looking at velocity. You can only spot it by looking at availability.

Two opposite failures from one wrong denominator

Take the hoodie again. Raw 30-day velocity 0.3, real in-stock velocity 0.75. A 14-day cover target says the store needs about four units on the raw number and about eleven on the real one. The review ships four, which lasts five days, and the cycle repeats: another two weeks out, another window at a third of true demand, another small transfer. Stores that run out get replenished less, which makes them run out more. Nobody chose this policy; it falls out of the denominator.

Now the manager gets tired of it and hand-carries 24 units from the hub on a Friday. Monday’s review reads 24 available at 0.3 a day — 80 days of cover, past any surplus ceiling — and proposes pulling twelve back to the hub as a rebalance. The busiest door for that SKU is now the recommended source, and if a rule auto-approves under twelve units, it happens without anyone reading it.

The third effect hits the spike detector. The first full week back in stock sells seven — 1.0 a day against a 30-day baseline of 0.3. That is a 3× divergence, and the anti-spike rule from the velocity windows post correctly flags it as a probable promo. It is not a promo. It is the door selling at its normal rate for the first time in three weeks, and the “spike” review holds up exactly the replenishment that would keep it selling. Restock rebound and promo spike are identical from the sales side. They are only distinguishable from the availability side.

In-stock-day velocity

The correction is not sophisticated: divide by the days the variant was actually sellable at that door, not by the days in the window.

• In-stock days = days in the window on which available was above zero at that location at the start of the day (or at any point, if the restock landed mid-day and sold).
• In-stock velocity = units sold at that location in the window ÷ in-stock days.
• Out days = window days − in-stock days. Lost units ≈ out days × in-stock velocity. Write it down; it is the number that gets a store manager and a finance lead to agree on the same transfer.
• Destination need = target days × in-stock velocity − available − incoming, exactly as before — the formula did not change, the rate did.

For the hoodie: 9 units ÷ 12 in-stock days = 0.75 a day; 18 out days × 0.75 ≈ 13–14 units the store would have sold and did not. Against a hub sitting on 60 days of cover, that is the entire argument for the transfer in two numbers.

Getting in-stock days out of Shopify

• Inventory history. Each variant’s inventory at each location has an adjustment history in the admin, with dates and reasons, and Shopify keeps roughly 90 days of it. Find the adjustment that took available to zero and the next one that took it back up; the gap is the out period. It is tedious per variant, so do it for A-SKUs at doors that had any zero day — not for the catalog.
• A daily available snapshot. If you already export the inventory CSV or your ops tool stores a daily matrix, count the days a variant-location shows available ≤ 0. This is the durable method; set it up before peak so the number exists when you need it.
• The cheap bound. Count the days in the window with at least one POS sale of that variant at that door. Days with a sale can never exceed in-stock days, so units ÷ days-with-a-sale is a ceiling on the real rate, and for a hero SKU that sells most days it is close. If that ceiling is more than about 1.5× the calendar-day rate, the door had an availability problem and deserves the full look.

Where the missing walk-ins reappear

Not every customer who found the shelf empty left with nothing, and the ones who stayed leave a trail — usually attributed to the wrong location.

• Ship to customer from POS. Staff ring the sale at the counter and the order ships from whichever location your routing assigns, typically the hub. Depending on whether your velocity counts the location that rang the order or the one that fulfilled it, that customer is store demand or hub demand. For placement they are store demand: they stood in Store 4. A door with a rising count of ship-to-customer orders on a SKU is a door that is out of it.
• Local pickup ordered online. The mirror case. Every channel report calls it an online sale, but it committed and deducted at the store and the customer walked in to collect it. Placement math should call it the store’s — and if your per-location velocity is built from fulfillment location, it already does.
• Sent to another store. Staff check another location’s inventory on POS and send the customer there. The sale, if it happens, lands at the other door and inflates its rate for a week. There is no order to reattribute; this is the case the in-stock-day correction exists for.

The rule that resolves all three: for sizing stock at a store, count demand where the customer stood or collected, not where the box shipped from. That is the opposite of the right answer for a hub, where ship-to region is the signal — which is why a store and a hub should never share one velocity definition.

Decision rules for retail doors

• A store is a transfer destination, not a source, for any variant whose in-stock days were under half the window. No surplus flag, no rebalance, no pull-back — whatever the cover math says. If your tooling supports location roles, mark POS-only doors as destination-only (location roles) so the donor failure is impossible rather than discouraged.
• A 7-day divergence at a door that had out days in the prior 30 is recovery, not a spike. Size from the in-stock 30-day rate; do not hold the transfer for promo review unless the promo calendar says otherwise.
• A retail destination target is the larger of two numbers: target days × in-stock velocity, and the presentation minimum — a full size run, a filled facing, whatever the floor looks like on that shelf. The presentation floor is not derived from velocity and should not be revised by it. A size that sells 0.1 a day still has to be present for the size run to sell at all.
• When the hub cannot fill every door, rank doors by lost units (out days × in-stock velocity), not by raw cover. Raw cover systematically ranks the door that was out longest as the least urgent.
• Any recommendation into or out of a store states in-stock days next to the velocity. “0.75/day on 12 in-stock days, 18 out, 13 lost” is a sentence a store manager can argue with. “0.3/day, 20 days cover” was wrong and looked fine.
• A door that has been out of a hero SKU for more than one full replenishment cycle is a purchase-order or allocation problem, not a transfer problem (PO vs redistribution timing). Transfers move a shortage around; they do not end one.

Rebuild one door’s numbers before the next review

1. Pick the store with the most “are we out at that location?” messages and its top ten POS variants by units over 90 days.
2. For each, open the variant’s inventory history at that location and list every period where available sat at or below zero in the last 30 days. Sum the out days.
3. Recompute velocity on in-stock days and put raw and corrected side by side, with lost units. Expect at least two of the ten to move more than 1.5× — if none do, this door’s problem is elsewhere, and inventory accuracy is the usual next suspect.
4. Re-run destination need on the corrected rate against the hub’s available, and check whether last week’s review proposed a pull-back or held a “spike” on any of them. Reverse those first.
5. Pull the last 30 days of ship-to-customer orders rung at that door and local-pickup orders collected there, by variant, and add them to the store’s demand for sizing.
6. Set the door’s presentation floors for those ten variants where the transfer review can see them. From now on, no recommendation for this store goes out without in-stock days on the line.

Sales data is honest about what sold. Retail demand is what would have sold, and at a POS door the gap between the two is invisible unless you look at availability first. Rebuild the rate on in-stock days, count walk-ins where they stood, keep stores as destinations, and the doors that kept running out stop being the doors your review is most relaxed about.