How to Use AI to Decide When to Reorder Inventory

Every inventory system eventually comes down to the same question: how much do you order, and when. Not “should you worry about stockouts” — that’s a different conversation. This one is narrower and more mechanical: given what you know right now, what number goes in the reorder field. Most WooCommerce store owners either guess at that number, copy whatever their supplier’s minimum order quantity happens to be, or reorder reactively once a product is already running low. All three approaches work fine right up until a product’s demand shifts, at which point they all quietly start being wrong in the same direction — too late, too little.

There’s a real formula behind this decision, and it’s older than ecommerce. What’s new is what you feed into it.

The Reorder Point Formula, In Plain Terms

Inventory planners have used a version of the same formula for decades: reorder point equals lead time demand plus safety stock. Netstock describes it plainly — lead time demand covers expected sales during the time it takes a supplier to restock you, and safety stock covers what happens when things don’t go exactly as planned.

Lead time demand is the straightforward part: multiply how many units you sell on an average day by how many days your supplier takes to deliver. If you sell 12 units a day and your supplier takes 10 days, you’d expect to sell roughly 120 units before the next shipment arrives. Safety stock is the buffer layered on top of that — extra units held specifically because “average” is never exactly what happens on any given day, and because suppliers occasionally run late.

Why “Average Daily Sales” Is the Weak Link

The formula itself isn’t the problem. The input almost everyone plugs into it is. “Average daily sales” is calculated by looking backward — most guidance recommends totaling units sold over the past 30, 60, or 90 days and dividing by the number of days to get a stable, representative number. That’s a reasonable approach for a product with genuinely flat, predictable demand. It’s a quietly broken approach for a product whose demand is about to change — because a 90-day average has no mechanism for knowing that, and it won’t reflect a real shift until weeks after that shift has already started eating into your stock.

This is the same lagging-indicator problem that causes stockouts at the worst possible moment in the first place, just showing up one layer deeper. A store that already caught a demand spike early still has to decide how much to actually order — and if the reorder math is still running on last quarter’s average, the early warning didn’t fully pay off.

Where a Forecast Actually Improves the Formula

This is the specific place a forecasting tool earns its keep — not by replacing the reorder point formula, but by replacing the number that goes into it. WhoKnew the Future™, the Meta Prophet-based forecasting engine built into WhoKnew Views™ Pro, produces a projected demand trend for each product rather than a flat historical average — the same underlying algorithm Meta uses to model behavior at platform scale, running against a store’s own view and sales data. Growth and changepoint alerts flag exactly when a product’s trajectory breaks from its recent baseline, which is the signal that a static average is about to become wrong.

Swapping a forecasted demand rate in for a historical average doesn’t change the formula’s structure at all — lead time demand is still average daily sales times lead time. What changes is which number counts as “average”: a projection that accounts for a detected upward or downward trend, instead of a number that’s mathematically guaranteed to be a little behind reality at all times.

What Safety Stock Actually Buffers Against

Safety stock has one job, and it’s not to fix a wrong demand estimate — that’s what a better demand rate is for. Safety stock exists to absorb the variability that exists even around a correct estimate: a supplier that’s usually 10 days out but occasionally takes 14, or a product that averages 12 units a day but sometimes sells 20 in a single afternoon for no obvious reason. Extensiv frames it as a function of desired service level, demand variability, and lead time variability together — the more unpredictable either sales or shipping tends to be, the larger a buffer is worth carrying.

This is worth separating clearly from the forecasting conversation: a better demand rate shrinks how wrong your baseline estimate is likely to be. Safety stock is what covers the gap that’s left over even after the estimate is good. Confusing the two leads to the two most common reorder mistakes in either direction — carrying a large safety stock to compensate for a demand number nobody trusts, or trusting a demand number so much that safety stock gets cut to nothing and a single bad week creates a stockout anyway.

Setting Lead Time Honestly

The lead time half of the formula gets far less attention than the demand half, and it’s usually the more dishonestly estimated of the two. A supplier’s quoted lead time and a supplier’s actual lead time are rarely the same number — quoted lead times tend to describe the best case, not the typical case, and a reorder point built on the optimistic number inherits that optimism directly. Tracking actual delivery dates against actual order dates for even the last five or six restocks usually reveals a real lead time meaningfully longer, and more variable, than whatever number is sitting in a supplier’s onboarding email.

Peak Traffic Detection data adds a second layer worth factoring in here: if a product’s highest-demand windows cluster around specific days or hours, and a supplier’s lead time spans one of those windows, the effective risk during that lead time is higher than a flat daily average would suggest — worth padding the safety stock slightly for that specific product rather than applying one blanket buffer percentage across the whole catalog.

Stores sourcing the same product from more than one supplier face a version of this problem that’s easy to get sloppy about: averaging the two suppliers’ lead times together and using that blended number for both. If Supplier A reliably delivers in 7 days and Supplier B takes 16, a blended average of roughly 11 days understates the real risk on any order actually placed with Supplier B and overstates it on orders placed with Supplier A — the fix is calculating lead time demand per supplier, not per product, whenever multiple sourcing paths exist for the same SKU.

A Worked Example

Take a product selling a historical average of 10 units a day, with a 14-day supplier lead time. The naive reorder point: 10 × 14 = 140 units of lead time demand, plus a safety stock buffer — commonly a percentage of that lead time demand, adjusted for how variable the product’s sales and the supplier’s delivery actually are. If demand and lead time are both fairly stable, a smaller buffer is defensible. If either swings widely, the buffer needs to widen to match.

Now suppose a changepoint alert flags that the same product’s daily rate has climbed from 10 units to a forecasted 18 over the past two weeks, with no sign of leveling off. Recalculating lead time demand against 18 units a day instead of 10 changes the base number from 140 to 252 — a 112-unit difference before safety stock is even added back in. A reorder point still running on the old 10-unit average would trigger a restock order roughly 44% smaller than what the current trend actually calls for, on a product that’s already accelerating. That gap is exactly where a stockout gets manufactured by the math itself, quietly, weeks before anyone notices the shelf is empty.

The Cost Runs in Both Directions

It’s tempting to treat “reorder too much” as the safe mistake and “reorder too little” as the dangerous one, but both directions carry real cost, just different kinds. Ordering too little on a rising product produces the obvious problem: a stockout during exactly the window demand is climbing, which is the most expensive possible timing for a store to run out. Ordering too much on a product whose demand rate was overestimated ties up cash in inventory that sits on a shelf, creates storage cost, and — for anything with any shelf life or seasonal relevance — risks becoming markdown stock later. Neither mistake is free, which is the actual argument for a demand rate that updates with reality rather than a static safety margin padded wide enough to cover for a number nobody fully trusts.

When to Actually Recalculate

Reorder points aren’t meant to be set once and left alone, but recalculating every single product weekly is more overhead than most stores need. A reasonable middle ground: recalculate immediately when a growth or changepoint alert fires on a specific product, recalculate on a fixed schedule — monthly is reasonable for most catalogs — for everything else, and always recalculate lead time itself after any restock that arrived later than expected, since a slipping supplier is a trend in its own right.

Reorder Point Answers “When,” Not “How Much”

It’s worth being precise about what the reorder point formula actually decides, because it’s a narrower question than it sounds. Reorder point tells you the inventory level that should trigger a new order — it says nothing about how many units that order should be for. That’s a related but separate calculation, generally called Economic Order Quantity, and it balances a different set of costs entirely: the cost of placing an order (which favors ordering less often, in bigger batches) against the cost of holding inventory (which favors ordering more often, in smaller batches).

The two numbers work together rather than compete. A rising, forecast-confirmed demand trend affects both — it raises the reorder point, since more units will sell during the same lead time window, and it can also justify a larger order quantity, since holding costs on a fast-moving product are a smaller relative risk than holding costs on a slow one. Getting the reorder point right without ever revisiting order quantity is a common half-fix: the store reorders at the correct moment, but keeps ordering the same fixed batch size it always has, regardless of whether that batch size still matches how fast the product is actually moving.

In practice, this shows up most clearly on a product that’s been trending upward for a month or two. The reorder point climbs correctly as the demand rate climbs — the store starts placing orders earlier — but if the order quantity itself never gets revisited, each order still only covers the same number of days of stock it always did, which on a fast-accelerating product can mean placing orders more and more frequently just to keep pace, when a larger batch size would have been the more efficient fix. Reviewing order quantity alongside reorder point, rather than treating the batch size as a fixed setting decided once at launch, closes that gap.

Who knew the reorder point sitting in a spreadsheet since launch day was quietly built on a version of your store that stopped existing months ago.