Warehouse picker performance metrics: picks per hour without the scan-time trap

What is picker and packer performance?

Picker performance is how many picks a worker completes per productive hour; packer performance is the same measure for packing. It is the central lever in a warehouse, because labor is usually the largest variable cost in a fulfillment operation. Anyone planning capacity, pricing a client fairly, or catching a bottleneck early needs to know what one person actually gets done in a shift - tracked separately for picking and packing, because the two have different cycle times and different levers to pull.

Picking means finding and pulling stock against a pick list. Packing means turning that pulled stock into a shipped parcel - boxing, labeling, generating the shipment. Packing performance tends to be the easier of the two to see clearly, because it happens at a fixed pack station where timestamps and a worker ID get logged in one place. Picker performance is the harder one, and it's the one this article focuses on.

Why scan-to-scan time overstates output

The most common measurement mistake is timing a picker by the gap between their first scan and their last scan in a shift - the scan-to-scan span. That number looks precise. It also silently treats every minute inside that window as productive, which is rarely true.

A worker is clocked in for nine hours but scans their parcels inside a two-hour window somewhere in the middle of the shift. Scan-span math shows close to 50 units an hour. Measured against the full clocked shift, the real rate is eleven. Both numbers are arithmetically correct - only one of them is honest, and only one is safe to build a staffing plan or a client quote on.

The gap between those two numbers is waiting time, staging, restocking, helping at another station, and breaks - none of it wrong to happen, all of it invisible if the denominator is a scan window instead of a full shift.

How do you measure it fairly?

The defensible formula is volume divided by actual clocked time from time tracking, not the scan-to-scan span between the first and last event.

• Units or lines per clocked hour, not units per scan window - only the first number is safe to use for staffing and client cost calculations.
• Don't hide non-pack time by counting it as productive, but don't silently strip it from the denominator either - both directions distort the number, just in opposite ways.
• Split by client when assortment or packing requirements differ sharply. A worker mostly handling one complex client structurally has different cycle times than one handling standard goods.

Framing matters as much as the formula. Picker performance is a capacity and planning tool, not a surveillance instrument. It answers how much staff a given volume needs and whether pricing on a client still holds up. It's a poor fit for a bare ranking with no context - comparing a worker against their own historical average and the team average is more useful than pitting people with different tasks against each other.

Why most warehouse systems don't hand this over directly

This is worth being precise about, because it's easy to overstate. Many warehouse systems genuinely do track who picked or packed an order, and show it inside their own screens - sometimes with leaderboards built in. What they often don't do is carry that person-to-order assignment through the interface a separate reporting layer connects to. The connection typically hands over orders, items, inventory and customer data - none of which ties a specific pick to a specific person.

That isn't a flaw unique to one platform - it shows up across warehouse management systems built primarily around inventory and order accuracy rather than labor analytics as a first-class export. The practical result is the same regardless of which system is running underneath: a reporting layer that only reads the standard order connection cannot claim picker performance as a number it pulled straight from the warehouse system, honestly.

The reliable route: time tracking plus login mapping

Because the identity gap is structural rather than a one-off missing field, the reliable source sits outside the warehouse system's own order data entirely: a time tracking system, paired with a mapping of scanner logins to the people behind them.

• Hours worked, per person - from time tracking.
• Who was on which station - from the scanner login mapping.
• Volume completed in that window - from the warehouse system.
• Result - minutes and volume per person, joined across the three sources.

The advantage of this route is that it doesn't depend on any single vendor's roadmap. It works the same way regardless of whether a given warehouse system ever exposes worker assignment natively, and it works identically across every system in a multi-site operation. Connecting time tracking alongside the warehouse system itself is covered under the systems a reporting layer reads from.

Are there benchmark numbers?

As rough, non-binding experience ranges only - never as a fixed target for an individual worker:

• Roughly 60 to 100 picks per hour for classic single-order picking, where a worker works through one order at a time.
• Roughly 120 to 200 picks per hour for batch or multi-order picking, where several orders are combined into one walk through the warehouse.
• Roughly 150 to 300 picks per hour with pick-by-light support, where travel time is cut through technical guidance.

These ranges are for rough orientation, not a target for any individual. A warehouse with bulky items or long travel distances sits structurally lower; one with small, densely stored goods sits structurally higher. The number becomes meaningful once it's compared against that same warehouse's own historical average for that same task - not against a number from a different operation entirely.

How the number should - and shouldn't - be used

Picker performance earns its keep in three places: staffing a shift against forecast volume, checking whether a client's pricing still reflects the real cycle time of their orders, and catching a slow day early enough to fix it rather than explain it after the fact at month end. It fits naturally next to the other client-level metrics a 3PL tracks, covered in full in the client and profitability view of a multi-tenant warehouse.

What it shouldn't become is a bare leaderboard shown without context. Two workers on the same shift can have very different real cycle times because of what they were assigned, not how hard they worked - a complex, multi-line client versus a simple, single-SKU one. A client portal that shows each brand its own operational numbers, without turning internal labor data into something clients see directly, is covered under a separate view per client. Pricing for a reporting layer that sits on top of this kind of setup is on the plans page.

Common questions