Safety stock for restaurants: why a flat 20% buffer is the wrong answer

Safety stock is the extra quantity held above expected demand to cover uncertainty. It is not the forecast itself, and it is not a promise that a stockout cannot happen. In a kitchen, the difference shows up on the prep list: the forecast is what you expect to use, and the buffer is the additional room you choose to hold.

A flat 20% buffer is easy to do in a spreadsheet. It is also a choice made without asking whether the item is predictable. It can pad a steady ingredient more than the evidence calls for and leave a volatile item short of protection. The percentage in this article title is a hypothetical rule of thumb, not a claim about what every kitchen does.

The buffer answers a different question from the forecast

A demand forecast estimates what you are likely to sell over a future period. A safety buffer covers some of the gap between that estimate and what actually happens. A good forecast can still miss. A good buffer does not erase that uncertainty; it makes the amount of protection explicit.

That distinction matters when the order cycle changes. If a supplier comes once a week, the kitchen needs cover for a shorter stretch than if the next delivery is several weeks away. A buffer expressed as a share of demand over that reorder period scales with the time the ingredient must last.

For each product, StocksSense uses average historical demand, converts the configured reorder cadence into months, and multiplies those together by a safety multiplier. The result is rounded to a whole unit. The reorder quantity then adds that safety stock to the forecast over the reorder period. In plain terms: how much the item usually moves during the wait, times how much extra cover its reliability calls for.

A modeled example with three ingredients

The table is a modeled illustration. Assume each ingredient has average demand of 100 units per month and a one-month reorder period. Those are assumed inputs chosen to make the multiplication easy; they do not describe a real account. The example assigns different backtested accuracy levels to show how the code's multiplier changes the buffer.

Each output in that table is modeled from the stated assumed inputs: 100 units per month × 1 month × 0.10 gives 10 units; × 0.20 gives 20 units; and × 0.50 gives 50 units. The calculation is deliberately simple. The hard part is choosing a multiplier that reflects evidence about the product rather than applying one preference to the whole menu.

Those percentages are not measured changes in waste, stockouts, or savings. They are modeled buffer amounts. Actual use depends on the product's forecast, the reorder cadence, and what demand does next.

How the product earns a multiplier

When enough sales history is available, StocksSense checks prior forecasts against the months that followed. It uses a rolling-origin backtest: train on the history available at a point in time, forecast forward, compare with what was later recorded, then repeat at later origins. That makes the comparison out of sample. The month being judged was not already included in the forecast that is being scored.

The reliability record keeps separate accuracy values for one-, three-, and six-month forecast horizons. For safety stock, the engine takes the longest available horizon score, falling back to a shorter one if a longer score is missing. This is product-specific: one ingredient can have a different record from another, even in the same kitchen.

When a backtested accuracy value is available, the multiplier bands are: 0.10 at 90% accuracy or higher; 0.15 from 75% to below 90%; 0.20 from 60% to below 75%; 0.35 from 45% to below 60%; and 0.50 below 45%. These are the engine's configured bands, not a measured promise of service or savings. A higher score selects a smaller buffer because that product's past forecasts have been closer to what came next.

The backtest needs at least seven sales observations before it can create a reliability result. That is the minimum training window of six observations plus a later observation to compare against. It is a data requirement, not a claim that every product will be predictable after seven observations; gaps can also make the history less informative.

What happens before a backtest exists

A new item cannot yet have a record of forecast errors. The engine does not pretend that it does. It calculates a coefficient of variation from the available demand history and assigns a low, medium, or high volatility tier. Larger variation can move the product into the high tier; a low tier requires enough observations as well as a narrow spread.

In the fallback, a low-volatility tier gets a 0.15 multiplier, a high-volatility tier gets 0.35, and a medium or inconclusive tier gets 0.20. So 20% can appear as the fallback for a product without a usable reliability result. It is not a universal rule applied permanently to every ingredient. As more evidence arrives, the reliability backtest can replace that fallback.

The reliability records are refreshed in a scheduled process and cached for seven days. A new record does not have to appear the instant a sale is entered. Until then, the forecast uses the available volatility signal. That delay is why a buffer can change as product history accumulates, even if the owner did not change the cadence.

What this method can and cannot tell you

Backtesting provides a record of past forecast performance for the product. It is useful evidence, not certainty about the next delivery window. A new menu, a price change, a promotion, a supplier disruption, or a change in portion size can make old history less representative. Review the line when the kitchen knows something the sales file does not.

The current engine also does not calculate the buffer from the spread of forecast errors. That approach was tested in the project's synthetic backtest and removed because it did not reduce stockouts at matched inventory levels. The shipped rule stays easier to inspect: average demand over the reorder period multiplied by the selected factor. That is a code and backtest result, not a measured customer outcome.

Accuracy is only one part of an ordering decision. It treats an over-forecast and an under-forecast as forecast errors, while the kitchen may care more about one direction for a particular ingredient. The backtest also cannot know whether you can use extra stock in another dish, whether a supplier delivers early, or how much room is left in the walk-in. Keep those practical constraints in the review.

Use the buffer as a reason to look closer

A smaller buffer on a steady line is not a command to cut tomorrow's order. It is a signal that the historical forecast has been relatively dependable for that product. A larger buffer is a prompt to ask why the line has been harder to predict and whether the extra cover fits your storage and spoilage constraints.

Look at the quantity beside the explanation, compare it with the walk-in, and use what you know about the next service period. If a product has too little history to earn a backtested multiplier, treat its fallback as a starting estimate. The number should help make the decision visible, not hide it behind a percentage.

A sales CSV export works from any POS; catalog sync with a supported POS is available when enabled for your account. To see how StocksSense turns sales history into a forecast and reorder guide, see the How it works page linked below, and for the statistical forecast feeding that reorder decision, the Holt-Winters explainer linked below.