People ask me what warehouse solution design actually is, and I'm never sure how to answer in one sentence. It isn't picking between AutoStore and a pallet shuttle. It starts three months before anyone orders a pallet shuttle, in a room with a spreadsheet, a customer who doesn't yet know what they actually need, and a list of questions nobody wants to answer.
Most of the decks I've seen go sideways because the design skipped the boring part and jumped to the fun part. Here's how I try to avoid that in 2026.
What the deck actually contains
The deck has pictures of racking and conveyors, but the useful content is in five places:
- SKU profile: how many SKUs, what shape, what ABC curve, seasonal or flat, hazmat or not, cold-chain or ambient.
- Throughput envelope: not just the average, but p50, p95, and peak-day orders-per-hour, with a realistic wave size.
- Dock and labor model: how many dock doors, how many shifts, how many people per shift, with overtime policy.
- Equipment topology: racking type, MHE, sortation, induction, pack stations, robots. This is what customers think solution design is. It's maybe 30 percent of the work.
- IT integration: WMS, WCS, ERP, TMS, OMS. Which system owns the order, which owns the stock, who resolves the fights. This is where projects die six months after go-live.
A good solution design is boring. It tells you what the warehouse will do on a Thursday in November at 14:17, and it is almost always right.
The inputs that decide everything
Before touching equipment, I want two datasets: 12 months of order lines (more if I can get them), and the current SKU master. Everything downstream is a derivative of these. A good first pass is just classifying SKUs by velocity. Nothing fancy, a quick ABC cut tells you 80 percent of what you need.
def velocity_class(sku_sales):
# sku_sales: list of (sku_id, units_shipped_last_12m)
# Returns {sku_id: 'A' | 'B' | 'C'} based on cumulative share of volume.
total = sum(u for _, u in sku_sales)
sorted_skus = sorted(sku_sales, key=lambda x: x[1], reverse=True)
out = {}
running = 0
for sku_id, units in sorted_skus:
running += units
share = running / total
if share <= 0.80:
out[sku_id] = "A"
elif share <= 0.95:
out[sku_id] = "B"
else:
out[sku_id] = "C"
return out
Run that, then ask: where do the A items live? Are they in the golden zone or scattered? How many touches does an average A item take from receiving to ship? The answers drive the equipment story in section four of the deck.
Three mistakes I still see in 2026
- Designing for peak only. Peak day is real, but it's one day a year. Sizing the whole building for peak leaves you 40 percent overbuilt in January. Size the base for p95 and buy flex for peak: agency labor, rented dock space, weekend shifts.
- Trusting the customer's demand forecast. Customers forecast what they want to happen. The order history tells you what has actually happened. When they disagree, the history is usually right.
- Ignoring the returns flow. Returns are 10 to 25 percent of outbound volume for ecommerce, and they come in sideways: mixed condition, mixed packaging, judgment calls per item. If the design doesn't have a returns process with a named owner, you've built a warehouse with a landfill attached.
If I had to pick one rule
Spend more time on the inputs than on the equipment. The fun part, picking robots, drawing rack elevations, rendering the layout, is downstream of the boring part. Every hour skipped upstream costs ten later. The best solution designs I've seen all look similar: unremarkable equipment choices, deeply understood data, and a returns flow that somebody actually thought about.