WES Task Logs: Picking Efficiency Dropped? Find the Bottleneck in 3 Steps

Here's the conclusion up front: when picking efficiency suddenly drops, don't call a meeting about your people — open your WES task logs first. I've seen this exact trap three times. Each time, management spent three days arguing about whether the pickers had gotten lazy, and each time the logs had the answer written in black and white, with zero to do with the people.

Here's why the logs beat the floor every time. After 30+ WMS go-lives, I've learned this: floor management sees results, task logs see the process. A picker says "I've been working nonstop." A supervisor says "he looked busy to me." All subjective. The log has timestamps, step transitions, and interruption records. When efficiency drops, it's always one of three things: tasks sat in the queue too long (an allocation problem), tasks took too long to execute (a floor problem), or tasks kept getting interrupted (a rework problem). Each leaves a different signature in the logs — they never overlap. That's what makes the 3-step method below work.

Quick 10-minute triage framework (details below):

1. Creation-to-assignment over 5 minutes (vs. your own baseline) → allocation strategy or system performance.
2. Assignment-to-completion 20%+ slower than baseline → floor execution problem.
3. Interruptions, cancellations, and reassignments doubled vs. normal → broken exception process.

Note: the 5 minutes and 20% are reference values from my experience. Your real comparison point is your own 4-week baseline, not my numbers.

Step 1: Check Queue Time in the WES Task Logs — Is the Bottleneck in Allocation?

Open the WES task logs, but don't start with individual tasks — start with the aggregate: how long did tasks sit in the queue between creation and assignment? I call this "queue time."

The exact procedure, in 4 steps:

1. Export the last 14 days of task logs. Compute daily median and P90 (90th percentile — never use the average; outliers will drag it around) of queue time.
2. Find the day efficiency dropped. Plot the two-week queue-time curve, 7 days before and after.
3. If queue time spiked on the same day efficiency dropped — the bottleneck is in allocation, not the pickers. Skip the people investigation entirely.
4. Queue time flat → allocation is innocent. Move to Step 2.

A project story. Fall 2024, a 3PL warehouse in eastern China, around 8,000 orders a day. Picking efficiency dropped nearly 30% in a week. Management's verdict: "the seasonal temps aren't cutting it," and they were about to replace a batch of people. I opened the task logs — queue time had jumped from a little over 2 minutes to more than 10. Tasks were stuck in the system; they never reached a human. Digging into the allocation records, I found that a "nearest-zone assignment" rule had been overridden by a new promo wave strategy, and the system was holding tasks to build bigger waves. Turned off the auto wave-building logic, queue time dropped back to 2 minutes the same day, and nobody had to be replaced. The temps nearly took the blame for a software decision.

Remember this: if efficiency dropped before a human even touched the task, the picker was never the problem.

Step 2: Compare Assignment vs. Completion Time — Is the Bottleneck on the Floor?

If queue time is normal and tasks are reaching people fine, look at the next leg: did assignment-to-completion time get longer?

The exact procedure, in 3 steps:

1. Take tasks for the same SKUs in the same zone, and compare assignment-to-completion time before and after the efficiency drop.
2. You must group by zone and by SKU profile (bulky vs. small, eaches vs. cases). Ungrouped, the data is mush — the bulky zone is always slower, and comparing against it is meaningless.
3. Whichever group shows a systematic slowdown — go look at that group on the floor, and cross-check against the interruption records in Step 3.

Another story. Late 2023, an e-commerce warehouse up north. Eaches-pick completion time went from around 40 minutes to over 60, while queue time stayed perfectly normal. The supervisor blamed the new hires for being slow. I had him group the task logs by aisle: Aisle A was fine, but every task in Aisles B and C was slower. Walked the floor — Aisles B and C were under racking reinforcement work, forklifts and materials blocking half the aisle, pickers detouring the whole shift. The logs had the answer all along: group by aisle, and it was obvious.

The biggest trap in this step is the "average trap." Warehouse-wide average completion time might only be up 10% — looks mild. But break it down by zone and one zone is up 60% while the rest are flat — the average hid the problem. My go-live eve checklist always includes this line: every efficiency metric must drill down by zone, by wave, and by shift. Otherwise the report is decoration.

Step 3: Read the Interruption Records in the Task Logs — Is the Bottleneck Rework?

Cancelled, reassigned, and timed-out tasks are the stealthiest efficiency killer. The pickers look busy all day — they're just busy redoing work.

The exact procedure, in 3 steps:

1. Count daily "task interruption" events: cancellations, reassignments, timeout auto-releases, abnormal closures.
2. Compute interruption rate = interrupted tasks ÷ total tasks, and compare against the 4-week mean.
3. If the rate doubled or more, look at the interruption reason distribution first: lots of stockout reassignments? Location exceptions? System timeout releases? The distribution points straight at the root cause.

A third story, and the most expensive one I've seen. Early 2025, a beauty-products warehouse. Efficiency down 20%, interruption rate at 3x normal. The reason distribution: 80% were "stockout reassignments" — tasks assigned to pickers, picker arrives at the location, no stock, task bounced back, reassigned. Root cause: receiving-to-putaway was running late, so system inventory didn't match physical stock. The warehouse did a full physical count over two weeks; once inventory accuracy recovered, the interruption rate dropped the same day and efficiency followed. Everyone on the floor had been firefighting for weeks, and nobody thought to look at the interruption reason distribution — the fire crew and the arsonist were the same process.

Bottleneck Lookup Table: Log Symptoms vs. What to Check First

A Counterintuitive Call: When Efficiency Drops, Don't Train — Read the WES Task Logs

The reflex in most warehouses is: efficiency drops → meeting → retraining → more headcount. My call is the opposite: a sudden efficiency drop is almost never a people problem — it's a process or system problem. People get slower gradually, not 30% overnight. A sudden drop means something changed — a strategy changed, the floor changed, inventory changed. WES task logs are the recorder of "what changed."

The trade-off, stated honestly: this method assumes your task logs are complete. Some WES implementations only log task creation and completion — no intermediate steps, no interruption reasons. Those logs are crippled; you can't diagnose from them. My go-live eve checklist requires this: task logs must record creation time, assignment time, start time, completion time, interruption events, and reasons. Every missing field is one blind eye during the post-mortem.

Closing: The 30-Minute Efficiency-Drop Checklist

1. Export the last 14 days of task logs; compute daily median and P90 queue time.
2. Compare the drop day vs. the prior 7 days: queue time up → check allocation strategy; flat → next step.
3. Group assignment-to-completion time by zone and SKU profile: whichever group slowed down, go inspect that group on the floor.
4. Compute interruption rate vs. the 4-week mean: doubled → read the interruption reason distribution.
5. Don't change any config or move any people until every conclusion has a matching timestamp in the logs.
6. After the fix, keep watching the same metrics for 3 days. Only close the case once they've recovered.

Efficiency problems always have their answers in the WES task logs. Data first, judgment second — never reverse that order.

By Lin Xiao, WMS Implementation Consultant