Reducing stockouts: why the fix is a record you can trust, not a bigger buffer

01 / FIELD NOTE

Keep the decision tied to the operating context.

The instinct when stockouts are frequent is to hold more stock. That response treats the symptom, because the stockout was rarely caused by holding too little — it was caused by believing you held more than you did. Adding buffer on top of an unreliable record adds cost and leaves the underlying error in place, and the error scales with the buffer.

The mechanism is straightforward. A stock figure is an aggregation of movements, and the aggregation drifts whenever a movement happens without being recorded or is recorded twice. Sales decrement it, receipts increment it, transfers reposition it, and shrinkage removes it without telling anyone. Over a season those unrecorded events accumulate into a figure that no longer describes the shelf, and the moment it disagrees with reality is the moment an order is accepted against stock that is not there.

That is the difference between on-hand and available-to-promise. On-hand is what the record believes exists somewhere. Available-to-promise is what can be committed to an order with confidence. A system can only narrow the gap between them by knowing more about each unit than a quantity: where it is, whether it is sellable, and whether it is already reserved.

Item-level identity is what makes that possible. When each unit carries its own serialized identity rather than a shared product code, the system can distinguish ten units of a product that are all present from ten units of which three are damaged, two are reserved and one is in the wrong location. The quantity is the same; the availability is not. A product-code count cannot make that distinction because the code is the same on every unit.

This is where the serialized identity carried in a tag’s EPC does work that a barcode cannot. A barcode identifies the product; a serialized EPC identifies the unit. Once units are individually identified, a read is evidence about a specific object, and the system can reason about reservations, location and condition rather than about a number that has to be maintained by hand.

Replenishment is the direct beneficiary. A reorder point driven by a trustworthy on-hand figure responds to what actually sold. The same reorder point driven by a drifted figure responds to the error as well as the demand — ordering to cover stock the system thinks exists, or failing to order because it thinks a shelf is fuller than it is. Most chronic stockouts are the second case.

Misplacement deserves separate attention because it presents as a stockout while being nothing of the kind. The goods are on the premises, on the wrong shelf or in the wrong zone. A quantity-based system cannot find them and will eventually reorder them, which converts a location error into a purchasing cost. Item-level visibility turns the same event into a directed search, because the last recorded location is known and can be checked.

The demand side has a mirror-image benefit. When availability is trustworthy, the business can commit to a longer horizon without holding safety stock against uncertainty, because the uncertainty it was insuring against was largely its own record error. Reducing the buffer is a consequence of fixing the record, not a substitute for it.

Counting is how the record is kept honest, and the frequency matters more than the thoroughness. A full wall-to-wall count is disruptive enough that it happens rarely, which means the record is only corrected rarely. Frequent counting of a smaller area — a zone, an aisle, a category — fits into normal work and corrects drift while it is still small. This is the practical argument for cycle counting, and it depends entirely on a count being fast enough that nobody resists it.

Exceptions are the output worth designing for. A count that produces matched, missing, unexpected, misplaced and duplicate categories gives the team something to act on and the business something to learn from. A count that produces a single variance figure tells you that you were wrong without telling you how, which is why the same discrepancy recurs after every correction.

The workflow around the count decides whether any of it survives contact with a busy shift. If the exception queue is buried, if resolving an exception takes longer than ignoring it, or if nobody owns the queue, staff will work around the system and the record will drift again — now with the added problem that the drift is invisible because everyone has stopped looking.

So the practical order of operations is: make the record item-aware, make counting cheap enough to do often, make exceptions visible and owned, and only then decide how much buffer the business still needs. The buffer is the last lever, not the first, and pulling it first is what turns a visibility problem into an inventory carrying cost.