A fixed low-stock number vs a calculated reorder point
A fixed low-stock threshold is a number you type once. Alert me when this SKU drops below 10. It knows nothing about how fast the SKU sells or how long your supplier takes. A calculated reorder point is the same alert with two inputs attached: the units a day the SKU actually moves, and the days your supplier needs to deliver. Multiply those, add a buffer for the weeks that run hot, and the number means something specific. It is the stock level at which ordering today still gets the next delivery in before the shelf is empty.
So the practical difference is timing, not sophistication. A flat 10 fires after the window has closed on a fast seller, and weeks before you need to act on a slow one. Same number, two failures, in opposite directions. Below is the arithmetic, the two inputs you have to own, and the handful of SKUs where a fixed number is still the honest answer.
The fast seller: 10 units is a day and a half of cover
A candle that moves 4 units a day with a 14-day supplier lead time burns 56 units while the purchase order is in transit. Add a modest buffer and the reorder point sits somewhere around 65.
Now apply the threshold of 10. The alert fires when you have two and a half days of stock left. You place the order the same afternoon, which is the best case, and the goods arrive eleven or twelve days after you sold the last unit. The alert was accurate and useless. It told you the truth at a moment when no decision could change the outcome.
This is the failure mode that hurts, because it lands on the SKUs that carry the store. Fast movers are exactly the items where lead time dwarfs cover, and exactly the items where a flat number set months ago is furthest from right.
The slow mover: 10 units is seven weeks of cover
Turn it around. A niche variant sells 0.2 units a day, roughly one every five days, with a 7-day lead time. It consumes about one and a half units while the order travels. The real reorder point is two or three units.
The threshold of 10 fires when you are fifty days from empty. Nothing is wrong. Nothing needs ordering. But the alert arrives, and then it arrives again, and the SKU sits in your low-stock list for two months looking like a problem. Multiply that across a few hundred long-tail SKUs and the list stops being a list of decisions. It becomes noise you learn to scroll past, which is how a genuine alert on a hero SKU gets missed.
The number stops being units and becomes days
The useful shift is not that the reorder point is a better number. It is that the question changes. A fixed threshold answers "how many are left." A reorder point answers "do I have enough days left to cover the order." Days of cover is the only unit a buyer can act on, because it is the only one that compares to a supplier's quoted lead time.
Once you work in days, the comparison across SKUs starts working too. A SKU with 9 days of cover and a 14-day lead time is already late. A SKU with 40 days of cover and a 7-day lead time is fine, whatever its unit count. You can sort by urgency instead of by stock level, and the two orders are not the same.
The two inputs you actually have to own
Everything else in the formula is derived. You own two numbers.
Velocity window. How much history counts as current sales. Restoc's reorder point engine uses a configurable window of 7, 14 or 30 days, and the choice is a real trade-off. A 7-day window reacts fast, which is what you want when a product gets a mention and the curve bends. It also treats one strange Saturday as a trend. A 30-day window is steady and ignores a one-off spike, which is right for staples and wrong during a launch. Fourteen days is the compromise most ranges tolerate. Pick per store, and revisit it after your first seasonal swing.
Lead time per SKU. This is the input merchants consistently guess low, because they remember the quoted lead time rather than the one they have been getting. Count from the moment you decide to order to the moment stock is sellable: your own approval delay, the supplier's dispatch, transit, customs if it applies, and goods-in on your side. Restoc takes lead time as a merchant input per SKU, and validates it server-side as a whole number of days within a sane bound, so a mistyped zero or a stray 3650 cannot quietly zero out a reorder point.
Where a calculated number needs guard rails
A formula with division in it fails in interesting ways, and a reorder tool that pretends otherwise is lying to you. Four cases matter:
- Zero-sales SKUs. No sales in the window means no velocity, which means a reorder point of zero. Correct, and also not a signal to order. It should read as "no signal," not as "healthy."
- Short history. A SKU live for four days cannot support a 30-day window. The number it produces is a guess dressed as a calculation.
- High variance. Twenty units in one day and nothing for a fortnight averages to the same velocity as steady trickle, and needs a very different buffer.
- Stock already at zero. The reorder point is academic. What you need is the order quantity.
Restoc's reorder point calculation is written as a tested pure function, with unit tests covering exactly those four cases and asserting the result is always defined and never negative. That is deliberately unglamorous work. It is also the difference between a dashboard you trust at 7am and one you check twice.
When a fixed number is still the right tool
Be honest about the exceptions. If a SKU ships in cases of 48 and you order one case a quarter regardless, the reorder point is decoration. If a supplier has a minimum order quantity that exceeds three months of demand, your constraint is the MOQ, not the velocity. And a brand new SKU with no history has nothing to calculate from, so a hand-set floor is the better placeholder until sales accrue.
The point is not that calculated beats fixed everywhere. It is that fixed should be a deliberate exception on a handful of SKUs, not the default across your whole catalogue because it was the only option the tool gave you.
What the alert should carry
An alert that says "low stock" sends you back to the dashboard to work out what to do. An alert worth reading carries the decision. When Restoc launches, it is built to pull real-time inventory and sales history from Shopify on install, show current stock, days of inventory remaining and reorder status per active SKU, and fire an email or Slack message when a SKU crosses its reorder point, through a background job that will not double-send the same crossing. The weekly report lists every SKU below its reorder point with a suggested order quantity, in-app or as a CSV you can hand to a supplier.
That is the whole argument for a calculated number. The threshold tells you something is low. The reorder point tells you whether to pick up the phone today.
Is a reorder point just a smarter low-stock threshold?
It is the same alert with two inputs attached: recent sales velocity and supplier lead time. A fixed threshold is a static unit count, while a reorder point moves as the SKU speeds up, slows down or changes supplier.
Which velocity window should I use, 7, 14 or 30 days?
Seven days reacts fastest and is the noisiest, 30 days is steady but slow to notice a change, and 14 days suits most mixed ranges. Restoc lets you configure the window, so pick one, then revisit it after your first big seasonal swing.
What lead time should I enter for a SKU?
Count every day between deciding to order and the stock being sellable, including your own approval delay, dispatch, transit and goods-in. Most merchants undercount by using the supplier's quoted figure rather than the lead time they have actually been getting.
What happens to SKUs with no sales history?
With no sales in the window there is no velocity, so the calculated reorder point is zero and should read as no signal rather than as healthy. Restoc's calculation is unit tested against zero-sales, short-history and zero-stock SKUs so it always returns a defined, non-negative number.