Most warehouse managers look at their WMS labor report and see a clean column of units per hour figures. The shift ran at 98 units per hour. The target is 110. The gap is 12. The instinct is to address the gap. But before you do, it's worth understanding exactly what those 98 units per hour include, what they exclude, and what the WMS quietly did with the time that doesn't fit either category.

WMS labor reports are not uniform across systems. They're not even uniform within the same system across different configuration choices. The number on the screen is always a product of what your WMS was told to count and how it was told to count it. If no one on your team made deliberate configuration decisions about labor reporting when the system went live, the defaults are probably giving you something close to the truth. Just not all of it.

What Direct and Indirect Labor Actually Mean in Your WMS

Every WMS separates labor into direct and indirect categories, but the definitions shift between platforms and even between deployments of the same platform. Direct labor typically means time spent on productive tasks: picking, putaway, replenishment, packing, receiving. Indirect labor covers everything else: meetings, breaks, equipment checks, cleaning, waiting for work. The boundary between those two categories is where reporting goes wrong.

In many configurations, travel time between tasks gets classified as direct labor because it occurs within an active task assignment. In others, the same travel gets dropped into a catch-all indirect bucket. The pick rate looks different in each scenario, and neither version is obviously wrong. But if you're comparing two associates or two shifts using that number, you need to know which version you're looking at.

The clearest way to check is to pull a single associate's labor detail for one shift. Look at the task start and end times against the actual directed task completions. If the total direct time exceeds what the tasks themselves would take at a reasonable pace, travel is almost certainly folded in. If the direct time looks low relative to the shift, the system may be dropping gap time into indirect without a clear reason code.

How Pick Rate Calculations Hide Travel Costs

Pick rate is the most-watched number in outbound labor reporting, and it's also the easiest one to misread. The standard calculation is units or lines picked divided by hours worked. That sounds simple. The problem is what counts as hours worked and whether the time a picker spends walking between locations is inside that window or outside it.

A WMS that starts the labor clock when a picker confirms the first pick in a wave and stops it at the last pick confirmation is measuring something closer to pure pick execution. It excludes the time to walk to the first location, the time to return the tote, and any gap between waves. A picker running 120 units per hour on that measure might be running 85 units per hour when you account for full shift time. Both numbers are real. They're describing different things.

Travel-per-pick is the metric that fills this gap, but most WMS labor reports don't surface it automatically. You have to calculate it from task completion data: total distance traveled divided by total picks completed, measured at the wave or shift level. If travel-per-pick is climbing over time and your pick rate is holding steady, your slotting or pick path is degrading. The productivity is staying flat because your people are getting faster at the actual pick motion while walking farther to get there. That trade-off ends eventually.

Where Idle Time Goes in the Report

Idle time is the hardest category to trust in a WMS labor report. Some systems log idle time explicitly when an associate has no active task assignment. Others absorb it into the last completed task, inflating the duration of that task without explanation. A few systems simply don't capture it at all, leaving a gap between clock-in and the first task start that the report can't account for.

The most common misread is interpreting inflated task duration as slow performance. If an associate's putaway tasks are averaging 12 minutes each when the engineered standard is 7 minutes, the instinct is to assume they're moving slowly. But if the WMS is attaching the 5-minute wait between task assignments to the prior task, the associate may be performing exactly at standard. The issue isn't execution. It's task queue management or wave design.

To check this, compare the sum of all task durations for an associate against their total shift hours. If the task durations add up to more time than the shift itself, something is being double-counted or miscategorized. If there's a consistent 30 to 45 minutes unaccounted for across most associates most shifts, idle time is either not being captured or is being folded into a bucket that doesn't surface in the standard view.

The Engineered Labor Standard Problem

Many WMS platforms support engineered labor standards: expected task completion times based on distance, task type, and product attributes. When configured correctly, these standards let you measure performance against a baseline that accounts for what the task actually required. When configured poorly, they become a source of persistent confusion.

The most common failure is standards that were set at go-live and never updated. If your pick path, slot assignments, or facility layout has changed since implementation, the engineered standards are measuring performance against a building that no longer exists. An associate hitting 95% of standard in a warehouse that's been re-slotted twice might actually be outperforming what the standard reflects. Or they might be underperforming in a way the stale standard is masking.

Check when your engineered standards were last reviewed. If the answer is more than 18 months ago or no one knows, treat the standards-based efficiency percentages in your labor report as directionally useful at best. They'll tell you who's relatively faster or slower within the current operation. They won't tell you whether the operation itself is running efficiently against what it should be capable of.

Building a More Honest Read From What You Have

You don't need to rebuild your WMS configuration to get a more accurate read on labor. Start by pulling task-level detail rather than aggregate shift summaries. Most WMS platforms store the raw task data even when the summary report obscures it. Task start time, task end time, location, units completed, and associate ID. That data lets you reconstruct what actually happened during a shift without relying on how the system chose to classify it.

From that task detail, calculate three numbers directly: average task duration by task type, gap time between tasks per associate, and picks per travel segment (if location data is available). Compare those numbers across shifts and associates. If gap time is high on one shift and not another, look at wave release timing. If task duration variance is high on specific task types, look at whether those tasks are involving exception handling that isn't being logged separately.

The practical step this week: pull one full shift of task-level labor data for your highest-volume pick zone. Calculate total gap time as a percentage of shift time. If it's above 15%, task queue management or wave cadence is the problem, not associate performance. If task duration variance exceeds 40% within the same task type, the tasks themselves are inconsistent, and that inconsistency needs a cause before it gets attributed to labor.

  • Gap time above 15% of shift time Points to wave release timing or task queue gaps, not slow associates. Look at how work is being released and whether there are consistent dead periods between waves.
  • Task duration variance above 40% within one task type Means the tasks aren't comparable. Exception handling, location inconsistencies, or system prompts are inflating some completions. Resolve what's making them different before using duration averages in any performance conversation.
  • Direct labor time exceeding actual shift hours A calculation error or a misconfigured labor clock. Audit the task start and end logic in your WMS configuration to find where time is being double-counted.
  • Standards efficiency percentages with no review date Use them to rank relative performance only. Don't use them to make headcount or coaching decisions until the standards have been validated against current facility conditions.