Why static reorder points fail, and what to use instead

A reorder point is a simple, powerful idea: when stock drops to this level, order more. Most inventory systems let you set one per product as a minimum, often alongside a maximum. Set them once, and the system tells you when to reorder.

The problem is the "set them once". A reorder point encodes assumptions about demand and lead time at the moment someone typed it in. Those assumptions start going stale the next day. This guide shows why, with a worked example, and what a reorder point that keeps up looks like.

Key takeaways

• A reorder point should equal expected demand over the lead time plus safety stock. Both change whenever demand or lead time changes.
• A fixed reorder point is too low when demand rises and too high when it falls — so it causes stockouts on growing and seasonal products, and excess on declining ones.
• Fixed maximums cause the same problem on the order quantity side.
• Forecast-driven reorder points recalculate from the current forecast and measured lead time, so nobody has to maintain them.
• If you must use static levels, express them in days of cover rather than units, and review them on a schedule.

What a reorder point should be

The reorder point exists to cover demand during the time it takes a new order to arrive:

reorder point = expected demand during lead time + safety stock

If a product sells 10 units a day and the supplier takes 14 days, you need 140 units to get through the lead time, plus safety stock for the days that are busier than expected or the deliveries that are late. Every input to that formula moves:

• Demand changes with seasons, trends, marketing, price changes and the competition.
• Lead time changes with supplier capacity, shipping routes and the time of year.
• Variability, which drives safety stock, changes too.

A static reorder point is a snapshot of all three. Our guide to safety stock and reorder points covers the formulas in detail; here we're concerned with what happens when they aren't kept up to date.

A worked example through the year

A product has a 14-day lead time. For simplicity, we'll set safety stock at 5 days of demand, so the correct reorder point is always 19 days of demand:

reorder point = (14 + 5) × daily demand

Early in the year, when the product sold between 11 and 12 units a day, someone set a static reorder point of 218 units — about 19 days of demand at that rate (218 ÷ 19 = 11.5). Here's what the correct reorder point would have been through the year, compared with the static 218:

The static level of 218 is roughly right in January and April, too high in July and dangerously low in October and November.

The cost in November

At 30 units a day, a reorder triggered at 218 units runs out after:

218 ÷ 30 = 7.3 days

But the order takes 14 days to arrive. The product is out of stock for:

14 − 7.3 = 6.7 days, or about 6.7 × 30 = 202 units of missed demand

That's per replenishment cycle, during your busiest month. And because those missed days look like low sales in your history, next year's planning starts from an understated November. Our guide to stockouts and lost sales explains why that compounds.

The cost in July

At 8 units a day, the correct reorder point is 152. The static level of 218 triggers orders 66 units early. If the maximum is also static, each order brings in more than the slow season needs, and the excess sits on the shelf — capital you could have spent on the products that were about to sell out in October.

The maximum is just as stale

Min/max systems order enough to bring stock back up to the maximum. If the maximum was set for April demand, it's too small for November (so you place more, smaller orders, each with its own shipping cost) and too large for July. The order quantity should reflect the demand over the period the order needs to cover:

order-up-to level = forecast demand over (lead time + review period) + safety stock

Like the reorder point, that's a calculation, not a setting.

Why static levels survive anyway

If static levels are this flawed, why are they everywhere? Because they're easy to understand and easy to implement, and for a while they work. A small catalogue with stable demand can run on min/max for years. The problems arrive gradually:

• The catalogue grows past the point where anyone can review hundreds of levels.
• A few products grow fast; their levels are never raised in time.
• Seasonal products swing too far for any single level to be right.
• Suppliers' lead times drift, and nobody updates the levels to match.

The usual response is a spreadsheet to recalculate levels quarterly. That's a forecast-driven reorder point with a three-month delay.

Forecast-driven reorder points

The fix is to stop storing the reorder point and start calculating it:

1. Forecast demand for each product over its lead time, using a method that handles trend and seasonality — see our beginner's guide to forecasting.
2. Use measured lead times from your own purchase order history, not the supplier's quoted figure.
3. Size safety stock from forecast error and lead-time variability, at a service level that suits each product's importance.
4. Recalculate regularly — nightly is ideal, since it costs nothing once automated.

The result tracks the seasons. In the example, the reorder point would rise from 228 in April to 380 in October and 570 in November without anyone touching it, then fall back to 152 for July.

There's one subtlety: in a ramp, the reorder point should use forecast demand over the coming lead time, not recent sales. In early October, recent sales say 20 a day, but the next 14 days may run closer to 30 as November approaches. A reorder point based on trailing sales is still one step behind; one based on the forward forecast isn't.

Stokrio's replenishment works this way: reorder points and order-up-to levels come from each product's forecast, its supplier's measured lead time and a service level that is higher for A-class products. Inventory alerts are checked against the same forecast every night, so there are no manual min/max levels to maintain.

If you have to keep static levels

Sometimes you can't switch everything at once. These steps reduce the damage:

1. Set levels in days of cover, not units. A reorder point of "19 days" automatically scales with recent demand, which fixes most of the trend problem. It still lags seasonal ramps.
2. Use separate levels for peak season. Set a Q4 level in September, and remember to switch back in January.
3. Review on a schedule. Monthly for A-class products, quarterly for the rest.
4. Update lead times whenever a purchase order arrives noticeably late or early.
5. Prioritise. Move best-sellers and seasonal products to forecast-driven levels first; stable, low-value products can stay static longest.

Static levels aren't wrong because they're simple. They're wrong because the world they describe keeps changing, and they don't.