Dynamic Wave Sizing in WES: Match the Wave to the Crew on the Floor

Let me give you the verdict first: wave size should never be a fixed number. However many people are on the floor, that is how many orders you release. I have been turning this over for years, and I am more convinced than ever.

Back in 2019, I was at an e-commerce fulfillment center in Fontana — 120,000 square feet, about 18,000 orders a day. Their WES had waves hard-coded: 400 orders per wave, released every 45 minutes, unchanged all year. First shift had more than 60 pickers; they burned through a wave in 20 minutes, then spent 25 minutes wandering the aisles, chatting, waiting for the system to drop the next wave. Second shift had 28 people; one wave took them two and a half hours, orders piled up ahead of the carrier cutoff, the supervisor was manually splitting waves, and customer service phones were ringing off the hook. I ran the numbers with their operations director: first shift was losing nearly twenty percent of its pick productivity to "waiting for waves." The people were not slow. The system was keeping them idle.

Put bluntly, a fixed wave size means running today's crew on yesterday's plan. The mismatch is guaranteed. Every warehouse has seen it: the most people on the floor when there are the fewest orders, and the fewest people when orders peak.

The fix is four words long in spirit: dynamic wave sizing. The WES stops releasing fixed waves and instead computes each wave from the real-time headcount on the floor. What I usually configure for clients is three tiers — the numbers get tuned per site, the logic stays the same:

The configuration logic is simple: every 15 minutes the WES reads the current on-floor headcount from the time-clock or handheld login system, takes a rolling average, and automatically shrinks the wave when the count drops a tier or grows it when the count climbs. One hour before the carrier cutoff, it locks down to small waves only, so everything clears the same day and nothing rolls over to tomorrow.

That wave size is not a guess — it is derived from headcount. Say average pick rate is 120 units per picker per hour, and 30 pickers are on the floor: that is 3,600 units an hour. A 600-order wave at 3 units per order is 1,800 units, cleared in half an hour — so a 30-minute release interval keeps the rhythm exactly matched. Drop to 15 pickers and the same 600-order wave needs a full hour, and the cutoff is suddenly in jeopardy. The formula is: wave size ≈ pickers on floor × units per hour × release interval ÷ units per order. Headcount moves, wave size moves with it.

In peak season 2022, I saw the other side of dynamic waves at an apparel 3PL. They had the feature turned on, but IT had configured it against "ideal headcount" — the system showed 45 people on the floor and sized waves for 45, while only 36 were actually out there; nine had clocked in and were still in the smoking area. The waves ran oversized, second shift failed to clear three days running, and the next morning's first wave was still chewing through yesterday's tail. I told their supervisor: if the input to dynamic sizing is dirty, the output will be wrong, guaranteed. Validate who is actually on the floor first — count handhelds logged in with real pick activity — and only then talk about dynamic.

Two configuration details most people miss on the first setup. First, the fallback: what happens when the WES cannot read headcount data at all? Network blips and time-clock maintenance happen. The right move is a fallback rule — when real-time headcount is unavailable, automatically reuse the headcount from the same time window of the previous shift instead of stalling. I have seen a site skip this; one time-clock server reboot froze wave releases for 40 minutes while dozens of pickers stood around. Second, how long should the sampling window be? Fifteen-minute sampling with a 30-minute rolling average is my usual starting point. Too short and waves swing wildly — pickers just adapt and it changes again, rhythm destroyed. Too long and the post-lunch surge from 20 to 45 pickers goes unnoticed for half an hour while orders pile up. There is no universal answer; run it for two weeks, look at the data, then tune.

Now the other side of the coin, because every solution has its price. First, temp workers are not full-timers. In peak season a temp typically picks at about sixty percent of a veteran's rate, so the headcount number has to be discounted or the waves still run hot. Second, smaller is not always better. The WES overhead of building a wave, assigning tasks, and printing labels is fixed; cut waves below about 50 orders and the system scheduling time starts eating a bigger share than the picking itself — pickers end up waiting on the system longer than they wait on freight. There is a floor; do not chase tiny. Third, small waves in idle hours sound great, but the pack stations and audit benches have to keep the same rhythm, or you release happily upstream and jam everything downstream.

I have seen too many warehouses pay for dynamic wave functionality and then have the supervisor keep releasing waves by gut feel — the system computes 200 orders, he "feels short-handed today" and bumps it to 350. That is the same as not having it. The biggest cost of dynamic waves is not the software; it is getting supervisors to watch the dashboard and trust the data. If the data says you have 22 people on the floor, accept it — do not go with "feels like 30."

Here is the counterintuitive part: releasing small waves in idle hours instead of letting orders accumulate looks like overkill, but per-person productivity actually goes up. What pickers fear most is not being busy — it is standing around. Once the rhythm breaks, it takes twenty minutes to get warm again. Keeping work continuously in everyone's hands is the real secret of throughput.

So: in your WES, are waves dead or alive? If they are dead, do not rush to replace the system. Ask your supervisor one question first: when the last wave was released, how many people were actually standing on the floor?

By Lao Mi, Supply Chain Veteran (20 yrs)