Why Best Sellers Keep Going Out of Stock

A reorder trigger is a fixed number. A sales rate is not. Everything below follows from that one mismatch, and it bites hardest on the products doing the most work, because a stale number is overtaken fastest where units move fastest.

This post is about a single fast-moving product and the parameters it was planned with. If your problem is the other shape, plenty of stock in total but the wrong stock, that is a portfolio problem rather than a per-product one, and it is covered in too much inventory but still out of best sellers.

Velocity outruns a fixed number

Take the SKU this site uses across its formula posts: "Cedar & Fig, 250g", planned at 5 units a day with a 12-day supplier lead time and a 30-unit buffer. That gives a reorder point of 90 units, and at 5 a day, 90 units is 18 days of cover against a 12-day lead time. Comfortable. Correct. Calculated properly.

Now suppose it takes off and settles at 11 units a day. Nothing about the calculation was wrong; one of its inputs simply moved. Ninety units is now a little over eight days of cover, and the lead time is still 12 days. The order still gets placed on the day the number is crossed, and the shelf still empties about four days before the delivery lands.

The same arithmetic explains why slow movers get away with stale numbers for years. A 20-unit planning error is four days of cover on a product selling 5 a day and under two days on one selling 11 a day. Every unit of imprecision is worth less time on a fast mover, so the fast mover is where a number that has not been touched in six months surfaces first.

This is not the argument that a typed-in low-stock threshold is a worse instrument than a calculated reorder point; that case, and its own diagram, live in the guide to Shopify low stock alerts. The problem here is narrower, because it survives doing the maths properly: a correctly calculated reorder point still goes stale the moment its inputs move.

Lead time against a growth rate

The second mechanism only appears on a product that is still accelerating, and it works on the order quantity rather than the trigger.

Suppose you size an order to cover 30 days at the current 11 a day: 330 units. Those units are ordered against today's rate and consumed against tomorrow's. If the product reaches 13 a day by the time the box lands, 330 units is roughly 25 days of cover, not 30. You are five days short before the delivery is even unpacked, and the next cycle starts from a lower shelf than you planned. On a growing product this repeats, and the shortfall accumulates rather than averaging out.

A trailing average makes it worse in a way that is easy to miss. Set velocity from the last 90 days on a product with a rising trend and the figure you get sits near the middle of that window: it describes the product as it was about 45 days ago. The lag is structural rather than an arithmetic mistake. On a flat product it costs nothing; on a growing one every planning number comes out systematically low.

The response is to shorten the window for products that are moving, and to plan a growing SKU against demand over the coming lead time rather than an average of the demand behind it. The general treatment of what still causes stockouts after the maths is right lives in preventing Shopify stockouts.

A flat buffer on a fast mover

The third mechanism is the safety stock line, and it is the same failure as the first one wearing different clothes. Thirty units of buffer on Cedar & Fig was six days of cover at 5 a day. At 11 a day the same 30 units is under three days.

This is why a house rule of the form "carry 30 units of safety stock on everything" fails asymmetrically. On the slow half of a catalog it over-buys, which is expensive but visible in the stock value. On the fast half it under-buys, which is invisible until something sells out, and it under-buys most on precisely the products where running out costs the most attention.

Sizing the buffer from a product's own demand variability and lead time, as the reorder point guide works through, produces a bigger number for a fast mover automatically. The point is not that best sellers deserve special treatment. It is that a per-SKU calculation gives them the treatment they need without anyone having to decide it, and a flat rule does not.

Promotions and pull-forward

Best sellers are the products you promote, so they absorb more promotional distortion than the rest of the catalog, and that distortion pushes planning numbers in both directions within a few weeks.

During the promotion, sales spike, and folded into a rolling average that spike inflates the next order for as long as it stays inside the window. After it, part of the demand you saw had been pulled forward from the weeks that followed: customers who would have bought in three weeks bought during the sale. The following period reads artificially quiet, so the order after that comes in short, just as the product returns to its real rate.

The net effect is over-ordering immediately after a promotion and under-ordering a month later, from the same unadjusted average. Estimating uplift and resetting the baseline afterwards is its own subject, covered in promotions and inventory forecasting. What matters here is which products carry the distortion: the ones you discount, which are usually the ones you cannot afford to run out of.

The fix is review cadence

All four mechanisms have the same root. A planning number was correct when it was set, the thing it described moved, and nothing checked. So the fix is not a better formula. It is recalculating often enough that the number cannot drift by more than one order cycle before someone looks at it.

Two things follow from that.

The reason most stores do not do this is arithmetic volume rather than disagreement. Recomputing velocity, reorder point and buffer weekly for the top of a catalog is a few minutes per SKU and a real chunk of a week across a full one, done every week, indefinitely. StockCue recomputes those numbers from live sales data rather than leaving them where they were last typed, using up to 24 months of order history, with demand forecasting on every plan including Free.

Frequently Asked Questions

Why do best-selling products stock out more often than slow ones?

Because the numbers that trigger their reorders are fixed and their sales rate is not. A trigger set when a product sold 5 units a day represents a certain number of days of cover; when the same product starts selling 11 a day, that identical number of units covers less than half as long, while the supplier's lead time has not changed. The faster a product sells, the faster any stale planning number is overtaken, so the best sellers hit the gap first.

How often should a bestseller's reorder point be recalculated?

Often enough that it cannot go stale by more than one order cycle. A practical rule is to recalculate at least as often as the lead time plus your review interval, and weekly for any product whose sales rate is visibly moving. Slower, steadier products can safely go months between recalculations, which is why a single review cadence across a whole catalog tends to be wrong at both ends.

Does raising the low-stock threshold fix it?

It buys time once, and then goes stale again in exactly the same way, because the new number is also fixed. Raising it is worth doing as an immediate patch on a product that is currently at risk. The durable fix is to express the trigger in days of cover, derived from current sales velocity and the current lead time, so that the unit figure moves on its own when the sales rate does.

Should a bestseller carry more safety stock than everything else?

In units, almost always yes, but that is a consequence rather than the decision. Safety stock is sized from a product's own demand variability and lead time, so a product selling more units per day arrives at a larger buffer through the same formula everyone else uses. The mistake to avoid is copying a flat unit count across the catalog, because that same number is weeks of cover on a slow product and a couple of days on a fast one.