Warehouse metrics
Every empty-location pick attempt,counted the moment it happens.
A pick-face stockout is a count: how many times a pick was attempted against a forward location holding no stock a picker could take, tallied as its own event rather than folded into a fill reading or a cycle time. WareBee logs the failed attempt where it happens — a scan against an empty bin, a task returned short — and rolls it up by location, zone and shift, so a rising count points at a place before anyone goes looking for it.
See what's behind the empty location
What it is
Counted at the location, the moment a pick comes up empty.
A pick-face stockout is a count: the number of times, within a shift, zone or location, a pick was attempted against a forward location with no stock a picker could actually take. WareBee logs the failed attempt as its own event the instant it happens — a scan against an empty bin, a task confirmed short or returned unfulfilled — rather than inferring it afterwards from a fill reading that happened to look low. Every occurrence is discrete and timestamped; the figure for a shift is a tally of those occurrences, not a percentage or a duration standing in for one.
The count climbs wherever a location was already thin and nothing intervened before a picker reached it, or wherever what the WMS reports as stocked and what's actually sitting there have quietly parted ways — stock physically in the building but not pickable from that spot, a pattern the twin catches by checking item, location and event records against each other rather than trusting a screen. A fast-moving SKU concentrated in one forward location, with a wave sending several pickers at it in succession, racks up a higher count than the same demand spread across more locations, independent of how quickly any single replenishment task runs.
A stockout count doesn't mean anything on its own — WareBee places it inside a peer set matched on order profile, SKU count and footprint before it decides anything about it. A site running a handful of high-velocity SKUs through a compact zone and one spreading picks thinly across a large, slow-turning catalogue will log very different counts for entirely legitimate reasons, and only a comparison against operations sharing your own order shape says which kind of count you're actually looking at.
What moves this number
What turns an empty location into a logged event.
Each one is measured on your digital twin from data you already generate, so a rising count comes with a cause attached, not just a location name.
A trigger that fires after the shelf is already bare
Replenishment set on a threshold or a fixed round has no view of a picker already on the way to that location.
When the reorder point sits below what the remaining wave demand actually needs, the location empties before the restock is even due. Task scheduling can instead treat the pick as the deadline a replenishment has to beat, not the other way round.
Several pickers routed at the same thinning location
A wave that sends more than one pick through a location in quick succession can outrun a single replenishment cycle.
Batching and routing decide how many picks land on a location before its next top-up arrives, so a location can look adequately stocked at wave start and still run out well before the wave closes. The twin sequences picks against remaining stock rather than treating every location as static.
The system says stocked; the shelf says otherwise
A pallet that's moved, been damaged or gone uncounted since the last transaction can leave a location reading full while it's actually empty.
The twin checks item, location and event records against each other on an ongoing basis, so a mismatch surfaces as a flag rather than staying invisible until a picker meets it. That gap counts toward the total the same as a genuine empty shelf.
A fast mover with nowhere else to draw from
A high-velocity SKU held in a single forward location has no second location to absorb the demand while a top-up is in transit.
Where the same SKU sits in more than one pick location, a picker can be redirected while the first location refills; where it doesn't, every gap between demand and replenishment shows up as a stockout instead of being absorbed elsewhere. Slotting decisions made months earlier still shape this count today.
One count, read against the wave it happened in.
A raw total tells you a location ran dry; it doesn't tell you whether that was a genuine stockout upstream or a replenishment task that fired too late or too far down the queue. WareBee checks each stockout against what the location's fill looked like at wave start and against the replenishment task history behind it, so the count splits into the two causes rather than sitting as one undifferentiated number a supervisor has to guess about.
From there it's a sequencing fix, not a headcount one. The task scheduler treats replenishment as a dependency a pick relies on, so a location trending toward empty gets restocked ahead of the wave that needs it rather than after a picker has already stalled. A revised trigger or priority rule is proven on the digital twin against the stalls it would have prevented before it changes a live task list.
- Stockout events grouped by location, zone and shift, not left as one warehouse-wide count
- Each occurrence checked against pick-face fill at wave start and the replenishment task behind it
- Sequencing changes tested on the twin before a revised trigger or priority reaches the WMS
Questions
Pick-face stockouts, counted and explained.
What exactly counts as a pick-face stockout?
One event: a pick attempted against a forward location holding no stock a picker could take, logged the moment it's confirmed empty or short — a scan against a bare bin, a task returned unfulfilled. Each occurrence is timestamped and attributed to a location, zone and shift on its own, so the total for a period is a sum of real occurrences rather than a rate applied after the fact.
Does the count include stock that's in the building but not pickable from that spot?
Yes. A location can read as stocked on the WMS screen while the pallet that would have covered it has been moved, damaged or gone uncounted since the last transaction — the location is still empty from where the picker is standing, and the attempt still fails. WareBee flags that mismatch by checking item, location and event records against each other, and it counts toward the total the same as a location that's genuinely bare.
Is 'pick-face stockout' a name from a published metric set?
No — it's WareBee's own plain name for a specific event the twin already logs: a pick attempted against nothing pickable. It isn't lifted from a benchmark report or a standard measure list, and it doesn't carry any threshold or target attached to it from outside; what it names is the count itself, defined here in WareBee's own terms and computed from your own event data.
How is a stockout count different from pick-face fill or replenishment cycle time?
They're three different kinds of number about the same problem. Pick-face fill is a level — how full a location is at a moment, typically wave start. Replenishment cycle time is a duration — how long a restock takes once it's triggered. A stockout count is neither; it's a tally of failed pick attempts, which can rise even while fill and cycle time both look reasonable, if demand simply outruns whatever combination of the two your operation is running.
Why not compare the stockout count to one flat figure?
A stockout tally means something different depending on where it happened — the same count logged in a slow-turning zone is a real problem, while your busiest fast-pick spot might log more than that on an ordinary day without anything being wrong. WareBee groups locations by order profile, SKU count and footprint, and only then reads a tally against locations pulling a genuinely comparable pace of demand, so what the number reflects is the zone that produced it, not a count read in isolation.
Does a fix for a recurring stockout location reach the WMS, or stay a report?
It reaches the WMS. Once a revised replenishment trigger, priority rule or slotting change is approved, it goes out as the replenishment and pick tasks your WMS already runs, timed to beat the pick rather than chase it. Only the locations actually driving the count change — the rest of the queue keeps its existing priority — and stockout events keep flowing back afterwards, so the next count reflects what genuinely happened at that location.