Warehouse Picklist Optimiser
Shipped11.2025 - 01.2026|3m
A picklist generator for high-throughput fulfilment that maximises units picked before fixed loading cut-offs, built around one operational insight about where the time actually goes.
The measurement
- Measured on
- generating every required CSV picklist end to end, about 1.24 operational days per minute
- Against a baseline of
- the schedule is built against fixed cut-offs and picker shift availability, not against a prior system
What it does
- The insight is that every picklist costs a fixed four minutes of setup and teardown - travel to zone, travel to staging - so the way to buy picking time is to consolidate into the longest lists the shift allows rather than many short ones.
- Picklist duration is set by workforce density in each window: 140 minutes while ~80 pickers are on shift, dropping to 50 minutes across the handover and the thinner day shift.
- Greedy construction fills a list until whichever of three hard caps binds first: the time limit, 2,000 units, or 200 kg - reduced to 50 kg for the segregated fragile lists.
- Capacity is computed on a 50-minute hour, an explicit 10-minute buffer for jammed racks and fatigue, so the schedule survives contact with a real floor.
- Look-ahead pulls work forward from future priority pods when the current queue empties, which banks work against the later shifts that have fewer people on them.
- The write-up names the failure points it found rather than hiding them: the two windows where staffing drops are where the schedule is most fragile, and the recommendation is a shift change, not a cleverer heuristic.
How it is put together
The win here is an observation about fixed costs, not a cleverer search. Both figures are about the constraint model rather than the code.
maximum picklist duration allowed in each priority windowa fixed 4-minute setup and teardown cost paid once per picklist, whatever its length
Every picklist costs a fixed four minutes of travel to zone and travel to staging. Consolidating into the longest list the shift can sustain converts four to six minutes of dead walking per cycle into picking. Capacity is computed on a 50-minute hour, an explicit buffer for jammed racks and fatigue, so the schedule survives contact with a real floor rather than only with a spreadsheet.
Show the numbers
| Window | Time | Pickers | Max minutes |
|---|---|---|---|
| P1 - P3 | 21:00 - 04:00 | 80 | 140 |
| P4 | 04:00 - 06:00 | 35 | 50 |
| P5 - P9 | 06:00 - 11:00 | 55 | 50 |
the order of operations, and what stops a list growingan unconstrained bin packing, which produces lists no picker could carry or finish
The caps are drawn as a race rather than a chain because that is what they are: the list stops at whichever binds first, and on a heavy-SKU zone that is weight long before it is time. The backwards arrow is the look-ahead, which banks work against the thinner shifts that come later.
Where it falls down
This is a greedy heuristic under hard constraints, not an optimum, and it was never measured against one - there is no bound here saying how much throughput a better scheduler would find. The four-minute setup cost and the 50-minute hour are estimates the whole strategy rests on; if either is wrong the consolidation argument weakens with it. Team project: the strategy and the constraint model are shared work.
Stack
- Python
- Pandas
- Greedy algorithms
- Bin packing
- Scheduling
- Jupyter