Short answer: E-commerce fulfilment automation should be specified against peak season — the promotional peaks when order volume multiplies — and justified against the average week, which is where it must also make sense. The systems that carry peaks best are the scalable ones: goods-to-person storage from suppliers such as Exotec and Geek+, robot-assisted picking, and software that re-plans waves as the order mix changes. The peak is the specification; the other fifty weeks are the business case.
Inbound and storage: where peaks are quietly lost
Peak problems often begin weeks earlier, at inbound. Goods arriving faster than they can be checked and stored become a yard of pallets and a stock record nobody trusts — and every downstream robot then automates the chaos faithfully. Peak-ready operations treat decanting and putaway as capacity to be planned like picking: scheduled supplier deliveries, enough storage headroom that the cube never runs completely full, and storage logic (such as the goods-to-person systems in the directory's listings) that spreads fast movers so no single location becomes the bottleneck everyone queues behind.
Picking under peak conditions
Picking is where the peak is won. Goods-to-person systems bring shelves or totes to stationary pickers, converting travel time into pick time and letting throughput scale by adding workstations and robots rather than by hiring and training hundreds of temporary walkers in a fortnight. The peak-specific questions are about the tail, not the average: how the system behaves when a few products suddenly dominate orders, how workstations are rebalanced between goods-to-person picking, packing and returns across the day, and what the queue looks like when one zone fails mid-shift. Amazon's fulfilment network is the industry's public reference for this architecture at scale, and Ocado's hive-style storage is its best-known alternative form — both useful as design references, whatever a given operator actually buys. The full warehouse picture beyond picking is covered in our guide to warehouse automation beyond the AMR.
The software peak: waves, cut-offs and promises
Hardware is only half the peak story. Order cut-offs, wave release logic and carrier collection times decide whether the physical capacity is ever used well: release work too early and workstations drown in half-picked orders; too late and picked orders miss the truck. Peak weeks are when the warehouse management system's quiet settings — batching rules, priority classes, the treatment of a VIP order against a thousand ordinary ones — become operating policy whether anyone chose them or not. Review those settings before the peak with the same care as the robot count, and change them then, not during.
Returns: the second peak nobody staffed
Peaks generate their own echo: returns arrive in a second wave, each item needing inspection, grading, repacking or disposal before it can be sold again. Returns processing automates less glamorously — workstations, scanning, imaging for condition records, routing conveyance — but its capacity decides how quickly peak stock becomes sellable stock again, and its backlog quietly consumes the space the next campaign needs. Plan returns capacity as part of the peak design, with the same seriousness as outbound, and measure the returns backlog in days as a peak health metric.
Temporary capacity: renting the peak
Because peaks are temporary, some capacity should be too. The options are structural: robot fleets that can be expanded with additional units for the season, robotics-as-a-service contracts that flex with volume, third-party logistics overflow for defined product ranges — the subject of our guide to robots for 3PLs — and the oldest flex of all, temporary labour, which automation changes rather than removes: fewer, more trainable roles. The planning error to avoid is buying fixed capacity for the peak hour of the peak day and carrying its cost all year; the opposite error, no surge plan at all, is merely more visible.
Rehearse the peak before it arrives
Peaks should be rehearsed like fire drills. In the weeks before: run the systems at simulated peak rates and watch where queues form; test the failure cases — a workstation down, a fleet software restart, a carrier collection missed; freeze changes to layouts, software and processes, because peak season is the worst debugging environment ever devised; and agree the escalation contacts and spare-parts posture with suppliers while they still answer the phone quickly. Operators who rehearse discover their bottleneck in a drill, at drill prices. Operators who do not discover it on the biggest revenue day of the year, at revenue-day prices.
Frequently asked questions
Why should fulfilment automation be designed for peak season?
Because peaks multiply order volume while service promises stay fixed. Systems must survive the peak week without failure — but they must also make sense in the average week, which is where the investment is actually repaid.
How do goods-to-person systems help at peak?
They bring storage to stationary pickers, converting walking time into picking time, and scale by adding workstations and robots rather than by hiring and training large temporary workforces at short notice.
Why do returns matter to peak planning?
Peaks generate a returns wave that needs inspection, grading and repacking before stock can be resold. Unplanned returns capacity becomes a backlog that consumes space and delays availability precisely when the next campaign needs both.
What belongs in a pre-peak rehearsal?
Simulated peak-rate runs to find queues, failure drills (a workstation down, a system restart, a missed carrier collection), a change freeze on layouts and software, and agreed supplier escalation contacts and spares — all before the peak, not during it.