Skip to main content
DoneThat

AI Adoption GuideRetailStock

Real-Time Stockout Risk Predictor

ML predicts near-term stockout risk from sales velocity, on-hand accuracy, inbound shipments, shelf capacity, and store execution signals.

Retail processPlanBuyPriceStockSellFulfillReturnClear

By Don, DoneThat’s AI coach · updated

What near-term stockout risk prediction covers

A replenishment planner does not need another overnight batch that says a store ran out yesterday. The useful signal is a short-horizon score: how likely this SKU-location is to hit a stockout before the next reliable replenishment lands, given what is selling, what the system thinks is on hand, what is already in transit, and how the store is executing.

This page describes an ML predictor that ranks near-term stockout risk for store (and optionally DC) locations. It is a prioritization and early-warning layer, not an autopilot. The model scores risk; replenishment still decides whether to pull forward a shipment, adjust a pack size, open a transfer, or leave the plan alone.

The predictor is most valuable when demand is bursty, on-hand books drift, and inbound timing is imperfect. Classic min/max and days-of-supply rules still matter as guardrails. They do not, by themselves, fuse velocity spikes, inventory accuracy doubt, inbound ETA uncertainty, shelf capacity limits, and store execution friction into one ranked view for the next few days.

Inputs the model needs, and when it should stay empty

The score should only run when the critical inputs are present and recent enough to trust. If sales velocity, on-hand, or inbound data is missing for a SKU-location, the system should emit no risk score for that row. A silent gap is safer than a confident number built on incomplete facts.

Sales velocity. Prefer short-window unit velocity (for example last 1–7 days), with seasonality and promo flags when available. Raw POS ticks help for sudden spikes; smoothed velocity helps for baseline. Without a usable velocity signal, near-term risk is not estimable in a way planners can defend.

On-hand accuracy. Booked on-hand is necessary but not sufficient. The model should consume accuracy or confidence features when they exist: recent cycle counts, perpetual inventory variance, shrink flags, or reconciliation outcomes. A high booked balance with low accuracy confidence should raise risk, or at least widen uncertainty, rather than look “safe.”

Inbound shipments. Open POs, transfers, and ASN/ETA windows are the main offset to burn rate. Missing inbound state is a hard stop for scoring: without knowing what is already coming, the model cannot separate “will stock out” from “will be covered tomorrow.”

Optional but high-value signals include shelf capacity and facing constraints (a full backroom does not prevent a hole on the peg), planogram or capacity limits that cap what can be presented, and store execution signals such as delayed putaway, missed picks, or open work that delays product reaching the shelf. Those enrich the score; they do not replace velocity, on-hand, or inbound.

How the score should behave for a planner

For each eligible SKU-location, the model produces a near-term stockout risk score (and preferably a short explanation of the main drivers). Typical horizons are one to a few replenishment cycles: long enough to act, short enough that the prediction stays falsifiable against what actually happened on the shelf.

Useful outputs for the workbench:

  • Ranked worklist by risk, with filters for category, store cluster, and lead-time band
  • Driver breakdown: velocity up, on-hand down or low confidence, inbound late or thin, shelf capacity binding, execution lag
  • Coverage gap view: expected demand before next inbound versus trusted available inventory
  • Change flags: risk that jumped since yesterday or since the last plan freeze

The planner’s job remains judgment. A high score during a planned promo with a known inbound may be acceptable. A medium score on a high-margin SKU with unreliable on-hand may deserve a count before any order change. Transfers, emergency replenishment, and pack-size decisions stay with the human (or with existing workflow systems the human already trusts).

Do not auto-commit order changes from the risk score alone. Wire the score into the same exception queue, allocation, or replenishment UI the team already uses, and require the same approvals those flows already require.

Operating the predictor in the weekly and daily rhythm

Daily (or intraday for high-velocity categories). Refresh scores after POS and inventory snapshots land. Re-score when ASN ETAs move or when a store reports a large adjustment. Present only actionable rows: risk above threshold, input completeness passed, and a feasible lever exists (order, transfer, count request, or presentation fix).

When inventory books are noisy. Pair risk with reconciliation. If on-hand confidence is low, the first action is often a directed count or a reconciliation task, not a blind push of more units. Otherwise you stock out on paper while overfilling the backroom, or the reverse.

When presentation is the constraint. Risk can rise while DC inventory looks fine if facings are wrong, capacity is capped, or product never reaches the shelf. Route those cases to planogram and shelf-availability workflows instead of treating every high score as a supply shortage.

Governance. Log score version, input snapshot time, and planner action (acted, deferred, dismissed with reason). That audit trail is how you catch model drift and process gaps without inventing performance theater. Review false alarms and missed stockouts by driver family: velocity miss, ETA miss, accuracy miss, execution miss.

Is this worth automating for you?

Whether this pays back depends on how much time it takes your team today. Most teams estimate that from memory, and the estimate is usually wrong in one direction or the other. This one is rated high effort to implement, so the baseline matters more than usual.

DoneThat reconstructs where the time actually went, with no timers to forget, so you can measure the baseline before committing to a project and check the gain afterward.

Measure the baseline first