One Wave, Two Workforces: How to Split Tasks Between People and Robots in WES

Bottom line first: inside a single wave, split tasks between people and robots using exactly two rulers — travel distance and judgment difficulty. Long hauls and repetitive full-case moves go to robots. Anything that needs eyes and a brain — irregular items, exceptions, piece-pick verification — goes to people. In WES, get three things right and the wave runs itself: task tags, resource pools, and a rebalancing trigger. I've seen this exact failure three times, and it always dies the same way: treating robots as cheap labor, until people and machines block each other in the same aisle and the wave runs slower than an all-human crew.

Why more robots made the wave slower

In WES, people and robots are two resource types, not two job titles. Releasing a wave means pushing a batch of tasks down to resources according to capability. But plenty of go-lives ship with exactly one allocation rule: "automate everything that can be automated."

In 2024 I worked on a 3PL site in Florida — 40,000 square feet, 120 AMRs and 60 pickers running the same wave. Week one after go-live, wave completion time was 18% worse than the all-human baseline.

The cause: AMRs had been assigned into dense manual piece-pick zones. Aisle width is fixed. People and robots moving against each other in the same aisle, yielding, re-routing — the takt time fell apart. The fix was unglamorous: zone by pick density. Dense small-item zones went human-only; AMRs handled long-distance replenishment and full-pallet moves and never entered a pick aisle. By week two, wave time came in 22% better than before go-live.

Here is the counterintuitive part: the thing to optimize in WES is not robot pathing — it is the human-robot handoff. A robot delivers on time to the verification station, nobody is there, and twenty robots queue up waiting. Handoff wait time routinely eats every second that path optimization saved. The prettiest routing algorithm on earth cannot rescue a handoff nobody designed.

Five steps to split the work cleanly

Step 1: tag every task. Add four fields to the WES task model: estimated travel distance, unit weight, item regularity (regular/irregular), and historical exception rate. Hard-code the tagging rules in the system — never rely on a dispatcher eyeballing it. No tags today means guesswork allocation tomorrow.

Step 2: build two resource pools with a capability matrix. A human_pool and a robot_pool, each carrying a capability sheet: people handle irregular items and exceptions but hate long walks; robots run around the clock with fixed payload but cannot spot a damaged carton or a misapplied label. The capability matrix is the only basis WES allocates on. Without it, the rules in step 3 are empty words.

Step 3: write three allocation rules. Steal these outright:

1. Any move with one-way travel over 80 meters goes to the robot_pool first;
2. Any task type with a historical exception rate above 5% is forced into the human_pool;
3. Split tasks for the same SKU in two: piece picking to people, full-case and full-pallet moves to robots.

Step 4: set a rebalancing trigger. Mid-wave, if either pool has tasks sitting unclaimed for more than 15 minutes, WES automatically shifts transferable tasks to the other pool. Put the threshold in configuration — do not make a dispatcher watch a screen and play firefighter. In 2025, an e-commerce warehouse in Dongguan released 2,000 tasks in one shot and 40 AMRs queued six minutes at the main aisle entrance. Switching to capacity-based staged release — one batch every three minutes — killed the queue outright. Release cadence follows the bottleneck resource. That is WES scheduling 101.

Step 5: run a week of data, then tune. Plot tasks on a distance-by-exception-rate scatter chart and set your rule thresholds at the visible boundaries — not by gut feel. The 80 meters, 5%, and 15 minutes are starting points, not gospel.

Go-live night checklist

I've seen this failure three times, so on go-live night I check exactly five things: ① all four task-tag fields populated, no gaps; ② the capability matrix is the current version, AMR payload matched against aisle widths; ③ the three allocation rules have run at least 50 waves in the test environment; ④ the rebalancing trigger threshold is in configuration and dispatchers know what the alert looks like; ⑤ handoff staffing is aligned with robot arrival takt. All five green or I don't sign — missing one means we delay. A one-week delay costs far less than post-go-live rework.

Four expensive failure modes

Failure one: using AMRs as cheap labor to directly replace pickers. People and robots moving against each other in the same aisle is a lose-lose — the Florida site paid tuition for that lesson.

Failure two: releasing the whole wave at once. Aisle capacity is a hard constraint; WES release cadence must follow the bottleneck. Dongguan's queue is the cautionary tale.

Failure three: exceptions with no owner. The robot flags an exception, people assume it's the robot's problem, and the task lies there for two hours. My rule: every exception defaults to the human_pool, and the WES alert goes straight to the shift lead's handheld.

Failure four: handoffs with no takt design. Two people at verification, twenty robots queued in front — in that kind of wave, more robots just means dying faster.

Something you can use tomorrow: don't buy robots first. Pull last month's tasks and look at them on a distance-by-exception-rate plot. If more than 60% land in the short-distance, low-exception quadrant, adding robots is burning money — fix the human travel paths first. Once the paths are clean, the WES allocation rules actually mean something.

By Lin Xiao, WMS Implementation Consultant