Redesigning the pick path mid-peak without breaking throughput

My position is simple: you can redesign a pick path during peak, but you cannot redesign it the way the slotting consultant drew it on the whiteboard in July. The only version that survives contact with a Black Friday wave is a staged migration that runs the old path and the new path in parallel for a week, on a bounded zone, with a rollback that takes one checkbox.

I hold that position because of what I keep seeing in the first ninety days after go-live. Teams who inherited a bad slotting plan want to fix it immediately. They can see the waste on every wave. The pickers are walking past the top ten SKUs twice because those SKUs live in the back of the mezzanine for reasons nobody remembers. Then October lands, orders double, and the same team that wanted to redesign in September now cannot afford to touch anything. So they wait until February, by which point the catalog has turned over and the analysis is stale again. The redesign never happens.

What does a pick path redesign during peak actually involve?

A pick path redesign is the re-sequencing of pick locations, zone boundaries, and travel order so that a picker’s route through the building matches the actual demand profile of current orders. In an apparel warehouse that means slotting against size curve velocity, not just SKU velocity, because a style that ships 400 units a week in a 2-4-6-6-4-2 size run behaves nothing like a style that ships 400 units of a single hero size. It means accounting for wholesale pack-outs and DTC singles sharing the same aisle. It means knowing which SKUs are allocated against committed wholesale pools and should not be touched by DTC pickers at all.

Doing this mid-peak is not a layout exercise. It is a migration against live order flow. The old path has to keep working while the new one is validated, because a wave that fails at 2pm cannot be re-run; the carrier cutoff is at 4.

The staged approach that actually holds throughput

Here is the sequence I would run on Monday morning if I inherited this problem in your seat. Pick one zone, ideally a bulk reserve or a secondary pick module, not the primary forward pick face. Re-slot that zone against the last four weeks of wave data, not against annual velocity. Peak demand is not annual demand averaged with a bow on top; the top 50 SKUs in November are often not in the top 200 in July.

Run both paths in parallel for five to seven working days. Route a small share of waves through the new slotting and keep the bulk on the old. Measure three things per wave: units per picker hour, short-pick rate, and the time from wave release to the last unit scanned to a tote. If any of the three degrades against the control group, you pause and diagnose before expanding. If all three hold or improve, you widen the share of waves on the new path the following week.

The part most teams skip: write down what rollback looks like before you start. In practice that means the old location IDs stay active in the WMS, the new ones are added rather than replacing, and the wave template has a flag that routes to one or the other. If you cannot flip back in under an hour, you are not doing a staged migration, you are doing a cutover and calling it staged.

This is the territory the warehouse execution scorecard was built to make visible, because the symptoms of a bad pick path (rising short-picks, waves missing cutoff, pickers logging more steps per unit) are exactly the symptoms of a dozen other BP5 problems, and you need to separate them before you touch slotting.

A worked number on when the parallel run pays for itself

Take a hypothetical operation: a wholesale plus DTC apparel brand running roughly 1,800 active SKUs across one owned DC and one 3PL, shipping to around 90 wholesale accounts with EDI compliance and a daily DTC flow of a few hundred orders. Assume the current pick path averages 42 units per picker hour at peak, and the redesigned path is projected (by the consultant, generously) to hit 58. Assume eight pickers working a ten-hour peak shift.

If you cut over cold and the projection is wrong, you can lose hundreds of units of throughput on day one across the full floor. On a wholesale wave with a retailer window, that is not throughput you make up on day two; it is late ASNs and chargebacks. If instead you run the new path on a small subset of waves for a week, inside a zone you chose because its waves are not retailer-critical, the same wrong projection costs you a fraction of that, bounded to one zone and recoverable the next shift. The parallel run costs you a week of slower improvement. It buys you the right to redesign in November instead of February.

The structural point underneath all of this

Pick path problems look like warehouse problems and they are, but the reason they persist is almost always upstream. If slotting cannot be redesigned against current demand, it is usually because current demand is not visible to the people doing the slotting, because inventory, orders, and warehouse execution live in different systems that reconcile overnight at best. That is BP5 of the 6 Breakpoints, and it is the one where the 3PL blind spot lives: you cannot slot against a demand profile you can only see three days later in a spreadsheet export.

The teams who redesign successfully during peak have one thing in common. Their warehouse execution sits in the same system as their order flow and inventory, so the wave data they slot against is the wave data running right now. The teams who cannot redesign during peak are usually running a WMS that talks to an ERP that talks to a cart, and by the time anyone agrees on what the top 50 SKUs actually are this week, the week is over.

If I were in your seat on Monday, I would not call the slotting consultant back yet. I would pull the last four weeks of wave-level data, pick the one zone where I can afford to be wrong, and write the rollback plan first. The redesign is a two-week project. The permission to run it mid-peak is a one-week project, and it starts with proving you can flip back.