The flat-number trap
Almost every store starts with one number. Alert me when anything drops below ten units. It is simple, it is easy to explain, and it is wrong in both directions at once.
On a product selling fourteen units an hour, ten units is about forty minutes of warning, and you will spend most of that forty minutes finding out whether anyone can act. On a product selling two units a month, ten units is five months of warning, delivered as an interruption, every single day, until someone mutes the channel.
Think in time, not units
The question a low-stock alert should answer is not "how many are left" but "how long until this is gone". Those are the same question only if everything sells at the same rate, which nothing does.
So set your threshold as a multiple of recent sales velocity:
- Take the last 7 days of unit sales for the variant.
- Divide by 7 to get a daily rate.
- Multiply by your restock lead time in days, then add a buffer.
A product selling 20 a day with a 5-day lead time and a 50 percent buffer wants a threshold around 150 units. The same rule on your slow mover gives you a threshold of 2, and the channel goes quiet.
The three exceptions
- New products have no history. Use a fixed number for the first fortnight, then let velocity take over.
- Launch products break their own averages by design. Watch them manually around a drop: averages need history that a launch, by definition, does not have.
- Seasonal spikes make a 7-day window lag reality. Going into your peak, shorten the window to 3 days so the threshold climbs with demand.
Look at your last five stockouts. If the alert fired less than one lead time before you ran out, your threshold was too low. The alert was technically correct and practically useless.
What to do about the noisy tail
Most catalogues have a long tail of products that will never justify an interruption. Do not tune them. Exclude them. Set a rule for your top fifty SKUs by revenue, and let everything else appear in the daily summary instead.
The goal is not complete coverage. It is that when the channel makes a noise, somebody looks up.
How Store Huddle surfaces low-stock alerts is covered in the help centre.
Why one number cannot work
A flat threshold across the catalogue is applying the same rule to products with nothing in common. A line selling forty units a week and one selling two both alert at ten, which is far too late for the first and pointlessly early for the second.
The number that actually matters is not units remaining. It is days of cover: how long the current stock lasts at the current rate. Ten units is a fortnight for one product and two days for another, and only one of those is an emergency.
Converting to days of cover is what makes thresholds comparable across a catalogue, and it is why the calculation in our reorder point guide starts from a daily sales rate rather than a stock level.
The lead time nobody measures
A threshold is only useful if it fires while there is still time to do something, which means it has to be anchored to how long replenishment actually takes.
Most stores use the supplier's quoted lead time. That figure is a sales number. The real one includes their dispatch delay, transit, any customs step, and how long the delivery sits in receiving before someone books it in. That last part is invisible in every supplier conversation and is frequently several days.
Measure your last three deliveries end to end and use the worst one. An average describes a typical week; a threshold exists to protect you in an atypical one.
Segment before you set numbers
Three groups, three approaches.
Core products get the full calculation and a generous buffer. Being out of stock on these is the failure the whole exercise exists to prevent.
The long tail gets a simple minimum. Computing a daily rate on something selling twice a month produces a meaningless number, and thresholds derived from noise fire at random.
Promoted or seasonal products should not use historical rates at all, because the future deliberately will not resemble the past. These need a planned buy and a trigger decided in advance.
Fixing a threshold that keeps being wrong
If an alert consistently fires too late, the lead time is understated, and it is almost always the receiving delay. If it fires constantly on a product that never runs out, the sales rate is inflated by a promotion or a one-off bulk order still sitting in the window.
Recalculate quarterly. Sales rates drift, suppliers change, and a threshold set a year ago describes a business that no longer exists.
Working an example
A product sells 3 a day. The supplier quotes seven days. Your last three deliveries took 11, 13 and 18 days from order placed to stock sellable, the 18 including three days sitting in receiving.
Use 18. With a seven-day buffer, the threshold is 3 x 25 = 75 units.
Setting it on the quoted seven days would have produced 3 x 14 = 42, and you would run out for roughly a week on every cycle while believing the calculation was sound. The quoted lead time is the single most common reason thresholds fire too late.
When the alert fires and nothing happens
A correctly calculated threshold still fails if nobody acts on it, and there are two usual causes.
It reaches the wrong person. Stock alerts should go to whoever places orders, and generally to nobody else. Wider distribution feels safer and reliably produces the assumption that somebody else is handling it.
Acting requires information the alert does not carry. If the recipient has to look up the supplier, the last order quantity and the current price before they can do anything, the alert has started a task rather than prompted an action.
Both are routing problems rather than threshold problems, which is why recalculating numbers does not fix them.
Thresholds during a promotion
Everything above assumes normal demand, which is exactly what a promotion suspends. A threshold calculated on ordinary velocity will fire far too late once a product is in an email going to your whole list.
For anything being promoted, raise the threshold for the duration and lower it afterwards. A rough approach that works: estimate the multiple you expect demand to increase by, and raise the threshold by that multiple.
Set a reminder to put it back. A permanently raised threshold on a product that is no longer promoted produces constant false alarms, and false alarms are how teams learn to ignore a channel.
What to do about products with no pattern
Some products genuinely sell erratically: three in a week, then nothing for a month, then five in a day. Averages describe these badly and thresholds derived from averages fire at meaningless moments.
For these, stop trying to calculate and use a simple rule instead: hold a fixed minimum, reorder when you hit it, and accept occasional stockouts as the cost of not tying up cash in unpredictable stock.
Trying to model unpredictable demand precisely produces confident numbers that are wrong, which is worse than an obviously rough rule everybody knows is rough.
Reviewing the numbers
Quarterly, and it takes twenty minutes. For each core product, check whether the daily rate still matches reality and whether the last few deliveries changed your lead time.
Also check the other direction: which thresholds fired without anyone acting? Those either reached the wrong person or were set at a level nobody believes, and both are worth knowing.
Bundles and kits
One case that breaks every threshold calculation quietly: a component that appears inside a bundle.
Its real demand is its own sales plus every bundle it is part of, and most stock reporting shows only the first. A threshold set on direct sales alone will fire long after the component has actually run out, and the first sign will be a bundle that cannot be fulfilled.
If you sell bundles, list their components once and set thresholds on combined demand. It is a ten-minute exercise that prevents a category of stockout no amount of watching the dashboard would catch.
Common questions
What should a low stock threshold be set to?
Enough units to cover your realistic replenishment time plus a buffer, which means it differs per product. A single number across the catalogue is late on fast movers and noisy on slow ones.
Should thresholds be per product or per variant?
Per variant. Product-level stock hides the fact that demand usually concentrates in two or three variants, so a product can look healthy while the sizes people want are gone.
What lead time should I use?
Your measured worst case, including receiving time, not the figure the supplier quotes. Quoted lead times routinely omit the days between delivery arriving and stock becoming sellable.
Why does my alert always fire too late?
Almost always an understated lead time, and usually the receiving step. Measure a few deliveries from order placed to stock sellable and the gap is normally obvious.
How often should thresholds be recalculated?
Quarterly, and whenever you change supplier. Both inputs drift, so a threshold that was right last year is describing conditions that have moved.