A stock count describes a position. An inventory decision usually needs a little more context: how quickly the item is moving, what is expected to arrive, and which commitments have already been made.
The following signals are starting points for a review process. They are not universal replenishment rules. Thresholds should reflect your products, delivery constraints, and the cost of getting a decision wrong.
Demand is changing faster than expected
A sudden change in sales can deserve attention, but it needs an explanation. A promotion, a price change, a closure, or a missing batch of transactions may all affect the number.
Compare like with like where possible. An item’s Saturday sales may not be a useful reference for Monday. A new product may need a different review process from a well-established item.
Before escalating, ask whether the change is large enough to affect a decision. A dramatic percentage on a very small base may be less consequential than a modest change in a critical product.
Replenishment is becoming less certain
Expected stock and available stock are different things. A purchase order may exist while its delivery estimate is outdated, its quantity has changed, or its receipt remains unconfirmed.
A useful review connects the incoming order with current availability and the demand expected before receipt. It should show the source of the delivery estimate and when that source was last updated.
The action may be a supplier check, a stock transfer, or a revised customer promise. Different actions belong to different owners.
Stock exists, but in the wrong place
A business can hold enough units overall and still struggle to fulfill a local order. Location matters, as do reservations, damaged stock, and transfer lead times.
Make sure “available” has a consistent definition. Physical stock, sellable stock, and stock available to promise are not necessarily interchangeable measures.
An exception should make the operational constraint visible. Moving stock may cost more than the sale justifies, or the destination may not receive it in time. The system should support that judgment.
Build a manageable review queue
Choose a small set of exceptions and review their usefulness with the people doing the work. Capture false alarms and explain why they were unhelpful.
For each signal, agree on:
The records and update times needed to interpret it.
The owner who can decide on an action.
The available response and its constraints.
A way to record the decision and outcome.
A queue that the team can understand and act on is a better starting point than a large collection of unexplained scores. Before adding more sophistication, check the data foundations behind those signals.
