In the fall of 2024 I sat in on a WMS demo for an e-commerce warehouse in Mira Loma, California. The sales rep talked for a full hour — intelligent wave optimization, digital twins, the works. The owner nodded along. The IT manager filled three pages of notes.
I raised my hand. "Pause. There's a rush order from a key account that has to ship today. Add it to the wave you just released. Live, please."
The demo specialist froze for three seconds, started digging through menus, clicked around for two minutes, and finally smiled: "We absolutely support rush orders — it's just not configured in today's demo environment."
Five seconds of silence. The owner closed his notebook.
I've watched that scene play out more times than I can count: dazzling on slides, helpless the moment a real warehouse scenario shows up. After sitting through a dozen WMS selections over the years, I've landed on one hard lesson — the feature checklist is the vendor's game, and every box comes pre-checked. Hand them your real scenarios and make them perform live, and that's your game. Nine out of ten vendors start sweating by the third scenario.
Here's my standing method: a week before the demo, I send the vendor five scenarios written from our actual operation — data masked, logic real. No slide decks allowed on demo day; everything happens live in the system. I don't ask "do you have this feature." I count mouse clicks, I watch how many screens they jump through, I check whether exceptions actually trigger alerts. A WMS gets touched thousands of times a day. Three extra clicks per task is hundreds of thousands of wasted motions a year.
"Drop a rush order into the live wave. Right now."
The scenario is simple: the wave is released, pickers are already walking the aisles with their RF guns, and customer service calls — a key account's order has to ship today, squeeze it into the current wave.
Three things to watch: can you inject an order into a released wave; does the new task push to the picker's handheld in real time, or wait for the next wave; does the half-picked wave get scrambled.
The classic failed answer: "We support rush orders, but you'd close the current wave and rebuild it." That's an instant disqualification. In a real warehouse you can't just close a wave — during peak season, with thousands of orders a day, closing a wave stops the entire pick line for half an hour. There's a sneakier failure too: he injects the order fine, but nothing shows up on the picker's gun until a supervisor radios everyone one by one. That tells you their "real-time" only exists in the slide deck.
The mixed pallet of returns is where systems go to die
Every WMS looks gorgeous on outbound. Returns are the lie detector. The scenario: a mixed pallet comes back — some units resellable, some with crushed packaging headed for disposal, and two cartons that were mis-shipped and came back with the return.
Watch for: does receiving the return auto-generate a QC task in one step; can a QC "scrap" decision trigger the disposal flow and inventory adjustment without rekeying; can the mis-shipped cartons link back to the original outbound order and spin up a replacement shipment.
Plenty of systems have a returns module that amounts to "you can type in a return." QC runs on paper, scrap gets tallied in a spreadsheet. In 2023 I watched a 3PL in Fontana let its returns area pile up for two full weeks during peak — when they finally cleared it, most of it went straight to disposal. The owner stood there watching pallet after pallet get written off, his face green. If the demo needs three screens and a free-text notes field marked "scrap this unit" to process a return, that's a fail — your returns clerk will never fill in that notes field. It'll be blank forever.
Slotting moves and inter-warehouse transfers: exposing the fake multi-warehouse
Before peak season, hot SKUs move from the upper levels down to the golden pick zone. Scenario one: generate move tasks for two hundred locations in bulk. Can the system do it in one shot, does in-transit stock show as in-transit or just frozen, and can move tasks auto-assign by picker work zone.
Scenario two is the killer: Warehouse A is short, Warehouse B has stock — transfer two hundred cases from B to A. Plenty of systems that claim multi-warehouse support handle this as an outbound order in B plus an inbound order in A, with the inventory vanishing into thin air for a day or two in between. Book inventory never matches physical. I ran one project that died exactly here — month-end variances so big finance refused to sign off, and the team spent three days cycle-counting.
A genuinely multi-warehouse architecture moves it as one document flow, with in-transit inventory visible end to end. During the demo, just count: how many screens, how many document numbers, and do they link to each other. More than two unlinked documents means you're looking at a fake multi-warehouse.
Hand the keyboard to the villain
The last scenario is my favorite. Create an account with picker-only permissions, then try to post an inventory adjustment, open the cost reports, and delete a confirmed outbound order.
Three things to check: do permissions go down to button and field level; does an unauthorized action get blocked with an error, or silently waved through; is there an audit log recording who tried to do what, and when.
The classic dodge is "permissions are fully configurable." Configurable and existing are two different things — make him configure one live, right now. If he can't, it doesn't exist. The worst I ever saw had exactly two roles: admin and operator. The operator could delete orders, adjust inventory, and read every cost report. The rep shrugged: "Small companies don't need it that granular." You're a small company today. What about in three years, with four warehouses? Migrating off a system at that point costs enough to make you cry.
Five scenarios in, you'll have eliminated seventy to eighty percent of the field. Negotiate price, timeline, and services with whoever's left — the foundation is already verified, so you can't lose badly.
But honestly, there's something that matters more than which vendor you pick, and it gets overlooked constantly: who wrote these five scenarios in the first place?
I've seen it too many times — IT leads the selection, the test covers APIs, architecture, and single sign-on, and not one real operational pain point makes it in. Go-live day arrives, IT signs off, and the pickers are cursing in the aisles: can't inject a rush order, returns run on paper, transfers run on spreadsheets. None of the questions IT asked matter on the floor.
So here's the question I'd leave you with: the next time your company selects a WMS, who gets to write the test? Because whoever writes the questions decides what system you end up buying.
