Warehouse metrics
Idle time, attributedto what actually caused it.
Automation throughput is what an AutoStore port, an AMR fleet or a pick tower actually clears against the pace it's rated for, with every idle interval attributed to the picking, replenishment or wave step that should have fed it — not folded into one blended reading. WareBee times the station and the process feeding it as one connected model, so a quiet hour resolves into a cause before it's read as a machine fault.
See the idle automation challenge
What it is
The idle minute that isn't the machine's fault.
On WareBee's digital twin, automation throughput is the volume of work an automated station — an AutoStore port, an AMR, a pick tower or a shuttle — actually clears, set against the pace it's rated to sustain, with every idle interval attributed to the picking, replenishment or wave step that should have queued the work rather than folded into one blended utilisation reading. WareBee times the station's own task completions against its rated cycle continuously, and cross-checks that against the upstream events feeding it, so a quiet hour resolves into a cause rather than a single ambiguous number.
The reading moves with what's actually queued in front of the station as much as with the station itself. Task allocation that hands work to whichever line is nearest rather than the automation actually built for it leaves a station under-fed while the manual aisles around it stay busy. A wave batched to keep a picker moving isn't automatically the batch a station needs to run without a gap, so automation running on unmodified pick-wave logic idles between releases it was never built to wait for. And a SKU assigned to an automated slot without being scored for it — on velocity, cube or order affinity — occupies capacity a faster-moving item actually needed.
A rated capacity number on a spec sheet says nothing about whether your station was ever going to be fed enough work to reach it — that depends on order profile, SKU count and footprint fixing how much genuinely automatable volume exists in the first place. WareBee checks those three before it reads a single throughput figure, matching your station against others asked to do a comparably shaped job, so a low reading against the wrong peer set stops being mistaken for a low reading against the right one.
What moves this number
What decides whether a station reads busy or starved.
Each one is measured on your digital twin from data you already generate, so a quiet station traces back to a cause rather than a general sense the automation isn't earning its keep.
Work queued behind the wrong process
The station is ready before the work is, and every idle minute gets logged as an automation problem by default.
Automation throughput is measured against the station's rated cycle, and every idle interval is attributed to the picking, replenishment or wave step that should have queued the work before it happened. Where the constraint sits upstream, re-tuning the machine changes nothing — the fix is re-sequencing what feeds it.
SKUs occupying a slot they didn't earn
Slow movers and awkward shapes sit in automated capacity a faster-moving item actually needed.
Every item bound for an automated slot is scored on velocity, cube, order affinity and seasonality before it's assigned there, not left to whatever the original go-live mapping decided. A slow mover sitting in a slot a fast mover needs shows up as lost throughput long before anyone walks the aisle to check.
A pick wave's batching reused as the station's own
A batch built to keep a picker moving isn't automatically the batch a station needs to run without a gap.
Where automation runs on the same release logic as the manual aisles beside it, the station clears its batch and waits for the next wave instead of running to its own rated pace. Batching into automation needs its own logic, built around the station's cycle rather than a picker's trip.
Stations balanced by assumption, not measured load
One port quietly absorbs more than its share while an identical one beside it sits idle.
Work is load-balanced across pick towers, shuttle ports and goods-to-person stations from measured throughput per station, not from the assumption that identical stations see identical volume. Left unchecked, that imbalance sets in gradually, and nobody assigned it on purpose.
Where the constraint actually sits, before the vendor call.
A single automation throughput figure can't say whether the station is the problem or the last stop in a queue that was already running late. WareBee reads yours against a peer set matched on order profile, SKU count and footprint, then breaks the gap down by cause — feed pace from picking and replenishment, SKU-to-slot fit, batching logic, or load balancing across stations — using the same task and telemetry data the station already produces.
From there it's usually a sequencing or allocation question rather than a hardware one. A revised task-allocation rule, a re-scored SKU list or a rebalanced station assignment gets tested on the digital twin against the volume already producing today's reading, so the throughput effect is visible before anything changes on the floor. Once approved, the change reaches the WMS as the assignment logic and priorities it already runs on.
- Automation throughput read against a peer set matched on order profile, SKU count and footprint
- Every idle interval attributed to feed pace, SKU fit, batching or station balance
- Allocation and slotting changes tested on the twin before anything changes on the floor
Questions
Automation throughput, traced to its cause.
What exactly counts as automation throughput?
It's the volume of work an automated station — an AutoStore port, an AMR, a pick tower or a shuttle — actually clears, set against the pace it's rated to sustain. WareBee times every task the station completes against that rated cycle continuously, and attributes each idle interval to the picking, replenishment or wave step that should have queued the work, rather than folding it into one blended utilisation reading.
How is automation throughput different from MHE utilisation?
MHE utilisation reads a truck class's hours against the task work available to it — forklifts, reach trucks, pallet trucks, measured by class and by hour. Automation throughput reads a fixed, installed system's own output against its rated cycle, with idle time attributed to the picking, replenishment or wave step that should have fed it. A yard can carry healthy MHE utilisation while a pick tower two aisles over sits under-fed, because the two are answering different questions about different assets.
Does low throughput always mean the machine is the problem?
No, and treating it that way usually points at the wrong fix first. A station can read low because task allocation keeps sending its work to whichever line is nearest rather than the automation actually built for it, because the wave batching it was never built around its cycle, or because the SKU mix feeding it was never resized after go-live. WareBee traces the gap to its actual cause before anyone opens a support ticket with the vendor.
Isn't the vendor's rated spec the natural benchmark for automation throughput?
Two operations can install the exact same station and still send it very different volumes of genuinely automatable work — one running a catalogue that scores well for goods-to-person, the other running mostly oversized or slow-moving stock the automation was never fed much of. Order profile, SKU count and footprint decide which situation you're in before any allocation or batching decision gets made. WareBee checks those three first, then reads your throughput only against stations asked to do a comparably shaped job.
What data feeds an automation throughput reading?
Task event history from the automation itself — what it worked and when — alongside the picking, replenishment and wave data your WMS already produces, is enough for a first read. Nothing about the core throughput comparison waits on a new integration project; the station's own task log and the upstream events already feeding it are what let a quiet hour resolve into a cause instead of a guess.
Does a fix for a starved station reach the WMS?
Yes. Once a revised task-allocation rule, a re-scored SKU list or a rebalanced station assignment is approved, it goes out as the assignment logic and priorities the WMS already runs on, so the change that improved throughput on the twin is the one the floor actually works to. Task and telemetry data then flow back afterwards, so the next reading reflects what the station genuinely did under the new rule.