Warehouse metrics
The rate is easy to read.What filled the hour isn't.
Lines picked per hour counts how many order lines an associate completes for every hour of paid time, per associate, per zone or per shift rather than blended into one site-wide average. WareBee builds it from pick-confirmation events on the twin's timeline and reads it alongside the standing, walking and handling split behind the hour, so a rate that's dropped has a reason attached to it rather than sitting as one number on a dashboard.
See where the hour actually goes
What it is
Counted from pick confirmations, read next to the hour around them.
On WareBee's digital twin, lines picked per hour comes from pick-confirmation events — a scan, a terminal or a WMS confirmation — logged the moment each line clears and counted against the paid hour it fell in, per associate, per zone or per shift rather than smoothed into one daily average. Because every confirmation carries its own timestamp, a hurried run before a cut-off and a slow stretch after a break both show up in the hour they actually happened in, instead of being blended into a single shift-long rate.
The number moves with how much of the hour was actually spent picking rather than getting to the next pick. Wearable and scan data split a shift into standing, walking and handling time, and when walking dominates that split while lines picked stays flat, the rate isn't telling you someone worked slowly — it's telling you most of the hour went somewhere else. Batch size, how the pick sequence maps to the floor, and whether fast movers sit close to where a picker is working all shape how much of the hour is left for picking once the walking is accounted for.
Before WareBee calls a lines-picked-per-hour figure anything at all, it places your operation inside a peer set matched on order profile, SKU count and footprint, because a site picking small, dense e-commerce lines and one clearing full-pallet lines for a handful of large accounts were never realistically going to hit the same count in an hour. Any rate compared outside that peer set — a published figure, a number pulled from an unrelated warehouse's dashboard — is a comparison against a shift that was never yours to begin with.
What moves this number
The hour, split by what actually fills it.
Each one is measured on your digital twin from data you already generate, so a rate that's slipped has a cause before it becomes a coaching conversation.
How much of the hour is walking, not picking
A rate that's dropped can mean someone is picking slower, or it can mean more of the hour is spent getting to the next location.
Wearable and scan data reconstruct a shift into standing, walking and handling time per associate, per zone and per shift, so a falling rate reads differently depending on which of the three grew. The twin shows the split, not just the count at the end of it.
Batch size and orders per trip
A picker collecting lines for several orders in one pass clears more lines in an hour than one walking the floor once per order.
Whether batching pays off depends on lines per order, SKU overlap and where those SKUs are slotted — read from your own order profile rather than assumed. Where orders share locations but never share a trip, each one pays for a lap a batch could have combined into the same hour.
Whether the pick sequence matches the floor
A list ordered by SKU or order number sends a picker back and forth between locations that sit right next to each other.
Routes solved as a true shortest path on the twin's real navigation graph reorder the stops themselves rather than walking a fixed list in the order it happened to print, so the doubling-back a static sequence keeps repeating stops eating into the hour.
Fast movers positioned to reach, not scattered
High-velocity SKUs sitting wherever they landed cost every pick list a detour that a well-slotted floor wouldn't.
The twin checks where each fast mover is actually slotted against demand velocity, item affinity and congestion, so a rate held back by scattered fast movers shows up as a slotting question rather than a pace one.
A falling rate has a cause, not just a number.
Once your lines picked per hour is read against a peer set matched on order profile, SKU count and footprint, the next question is what's actually filling the hour — walking, waiting, a batch that's too small, or a pick sequence that keeps sending someone back across ground they've already covered. The same standing, walking and handling split that builds the figure breaks it down to cause, so a slow rate reads as a specific problem rather than a general sense that the team should move faster.
From there it's a routing, batching or slotting question, not a pace one. WareBee replays your real order history through candidate routes, batch sizes and slotting moves in the digital twin and reports the lines-per-hour effect of each before anyone walks it, so the change that reaches the floor is the one already shown to work on your own orders.
- Lines picked per hour read against a peer set matched on order profile, SKU count and footprint
- The hour split into standing, walking and handling, not left as one blended rate
- Routing, batching and slotting changes tested on the twin before a live shift changes
Questions
Lines picked per hour, without the guesswork.
What exactly counts as a 'line' in this rate?
A line is a single order line cleared at the pick face — one SKU and quantity confirmed against a pick task, whether the confirmation comes from a scan, a terminal or a WMS update. Lines picked per hour counts confirmed lines against the paid hour they fell in, per associate, per zone or per shift, rather than a shift total divided by however many hours the shift happened to run.
Does a low rate always mean someone is picking slowly?
No, and treating it that way usually points at the wrong fix. A rate can fall because the picking itself slowed down, or because more of the hour went to walking, waiting on a blocked aisle, or a batch too small to make a trip worthwhile — three different problems that look identical as a single number. Splitting the hour into standing, walking and handling is what separates a pace problem from a travel or batching one.
How is lines per hour different from travel distance per line?
They measure different sides of the same shift. Lines picked per hour is a rate — output against paid time. Travel distance per line is a distance — how far a picker walks to clear each line, regardless of how quickly they're moving. A route can be short but still picked slowly, or long but picked fast, so reading the two together tells you whether a low rate is a distance problem, a pace problem, or both.
What data does a lines-picked-per-hour reading draw on?
Pick-confirmation events, order and pick history and your WMS's task data are enough for a first read — the exports most operations already produce, not a new integration project. Wearable and forklift telemetry sharpen the standing, walking and handling split further where you already have them, but they refine a working measurement rather than being required to start one.
Why won't WareBee just tell me what a good rate looks like?
A published 'good rate' can only describe the operation it was measured on, and that's rarely going to be yours. Line count per order, how far apart locations sit, and how a batch gets built into a route all push the achievable rate in different directions, before a picker's actual speed even enters the picture. WareBee's peer set — order profile, SKU count and footprint — keeps the comparison honest instead: your rate gets read against operations picking a broadly similar mix, not against a benchmark measured on someone else's shift.
Does a routing or batching change reach the WMS, or stay a suggestion?
It reaches the WMS. Once a change is proven on the digital twin against your real order history and approved, it goes out as the pick sequences and batch assignments your WMS already runs on, so the change that improved the rate on screen is the one the floor actually works to. Actuals flow back afterwards, so the next read starts from what genuinely happened rather than from what was planned.