Bottom line first: WES returns wave processing comes down to one rule — return tasks get their own waves and their own priority band, and they only fill gaps in outbound waves when labor and equipment are genuinely idle. Dropping return tasks into outbound waves looks efficient. In practice it makes two groups of tasks fight over the same people, equipment, and slots in the same window. I have seen this mistake three times, and all three fixes were the same: pull returns out of the outbound wave.
Why can't returns ride along with outbound waves? Because the two waves run on different clocks. An outbound wave runs on the carrier cutoff clock. Miss it by a few minutes and the shipment waits until the next pickup. A returns wave runs on the refund clock and the inventory-recovery clock. A day late means a customer chasing a refund in the support queue, and a resalable item spending another day sitting in the returns area. Put both clocks in one wave and the WES priority engine can only serve one of them. The other one loses.
Returns volume is not a rounding error, either. According to the NRF and Happy Returns' 2025 Retail Returns Landscape report, roughly 19.3% of US online sales were expected to be returned in 2025, and retailers expected about 17% of holiday sales to come back. Do the math on that: for every 1,000 orders shipped, around 193 items come back. Adobe's data adds that return volumes surge 25% to 35% in the days right after Christmas. So the returns flood arrives exactly when outbound is busiest. Without a separate returns wave plan, it will swamp the outbound wave.
Last January, a 3PL warehouse in California that handles apparel walked straight into this trap. In the first week after the holiday peak, their WES was inserting return-receiving tasks directly into the day's outbound picking waves. The logic was "a task is a task, whoever is free does it." Then returns volume spiked, pickers kept getting dispatched to the returns area to open boxes, and the cutoff wave's picking progress stalled. Several batches of outbound orders missed the carrier pickup that day. Worse, inspected returns had nowhere to go, so graded goods piled up in the aisles, and the next morning's forklifts could barely get through. When I arrived, the warehouse manager's first words were: "We don't have a headcount problem. The system keeps sending people to the wrong place." The fix was not complicated: pull return tasks out of outbound waves, give returns their own waves in two fixed daily windows, and only release extra return tasks into outbound gaps once idle labor was confirmed. Within a week, cutoff waves were back on schedule.
The second story is the mirror image — the problem was priority, not wave structure. Another warehouse, handling home goods, shared forklifts and slots between returns putaway and outbound replenishment. The WES scored returns putaway and outbound replenishment with the same priority rules, so returns putaway frequently outranked replenishment. Result: returns went onto shelves one by one while pick faces ran dry, and outbound orders sat waiting at the pick station. The root cause: "returns putaway" was treated as equally important as "outbound replenishment." The value of a returns putaway depends on whether the item can be resold quickly. A return that can go straight back to stock deserves a fast lane. A return that needs repair, cleaning, or is already out of season does not belong in the pick area at all. We split returns putaway into two paths: directly resalable returns got a fast lane, ranked just one notch below the cutoff wave; everything else went to a returns holding area for batch disposition. Shortage alerts dropped sharply the same day.
Three Ways to Schedule WES Returns Waves: Separate, Mixed, or Hybrid
No universally best option — only the one that fits your building.
| Approach | How it works | Best for | Resource-conflict risk |
|---|---|---|---|
| Separate returns waves | Return tasks form their own waves in fixed windows, offset from outbound waves | High return volume, mixed categories, post-peak surges | Low — resource boundaries are clear |
| Mixed into outbound waves | Return tasks drop straight into the day's outbound waves under the same rules | Very small return volume, a few pieces here and there | High — cutoff windows get hit first |
| Hybrid: fixed waves + idle fill | Returns have fixed waves; extra return tasks fill outbound gaps only when outbound finishes early | Day-to-day reality for most warehouses | Medium — depends on how accurately idle capacity is judged |
My recommendation for WES returns wave processing: default to the first or third option, and never treat the second as normal operations. The mixed option only works when returns are small enough to ignore, and given the NRF numbers above, most warehouses selling online do not qualify. The hybrid option has one precondition: the WES must judge idle capacity in real time from system data, not from a supervisor eyeballing the floor. Otherwise the hybrid quietly slides back into the mixed model.
Prioritizing the Returns Wave: Four Rules
Inside the returns wave, first-come-first-served does not cut it. Four rules, in order:
- Outbound waves inside the cutoff window always outrank every return task. No exceptions: a late return is a customer-experience problem; a missed cutoff is a broken promise. In the WES, cap return-task priority below the outbound band.
- Resalable returns outrank returns needing repair, cleaning, or disposal. The value of returns work is inventory recovery: an item back in stock a day earlier sells a day earlier, while an item needing repair may never sell after the work. It waits.
- Returns approaching their refund deadline jump the queue. Refund promises have countdowns. The WES needs to carry each return's refund deadline as a task field and auto-escalate priority as the deadline approaches. Without that field, whoever complains loudest gets served first.
- Returns do not get put away into pick slots. Returns awaiting batch disposition go to a holding area, not into pick slots "just to get them off the floor." Pick slots are for goods that can sell.
Splitting Waves at Peak Season, and Setting Returns SLAs
During the post-peak returns surge, do not schedule returns waves as "process whatever shows up." Split by disposition path. My cut is three slices: by return reason — quality, wrong size, and no-reason returns separate, since their inspection standards differ; by disposition path — direct-to-stock, needs inspection, and scrap-or-repair each run their own wave; and by arrival batch — oldest first, so new arrivals never bury old stock. Do not guess wave size. Work backward from the returns area's actual staffed stations: however many units one window can genuinely process is how many units go in that wave. The overflow rolls to the next wave.
For SLAs, do not copy someone else's numbers. Work backward instead: start from the refund promise you made to the customer, derive the inspection completion time from it, then derive the receiving and putaway time from that. Set three SLAs: shortest for direct-to-stock returns; capacity-based for inspection-needed returns; loosest for repair-or-scrap, but with a firm batch-disposition cycle so nothing sits in holding indefinitely. One critical point: the SLA has to live in the WES task priority field, so the system escalates automatically as deadlines approach — not in an SOP document that relies on people remembering.
The Go-Live-Night Checklist: Five Things That Go Wrong
Every go-live night, I walk this list item by item:
- Do return tasks have their own wave type and priority field in the WES, or do they share one set of rules with outbound tasks?
- Are returns wave windows offset from outbound cutoff windows — at minimum, not fully overlapping?
- Is the putaway destination for returns a pick slot? If yes, change it to the holding area or a dedicated returns zone.
- Does the refund deadline make it into the task fields, and can the WES auto-escalate priority as it approaches?
- Are inspection standards in the system — what counts as direct-to-stock, what goes to repair? If not, inspectors will ask you about every item.
One last honest word: WES returns wave processing shows its true quality in the first week after peak season. When volume is small, every method looks fine. When the flood arrives, separate-wave warehouses process in an orderly line; mixed-wave ones spend the week firefighting. Go look at your WES today and check whether return tasks have an independent wave type and priority field. If not, fix that first, and worry about the rest later.
By Lin Xiao, WMS Implementation Consultant
