Every WMS vendor shows you the same demo. A clean inbound receipt, a tidy wave release, a picker who walks a logical path and scans perfectly on the first attempt. Orders complete. Inventory updates. The screen refreshes. Everyone in the conference room nods.

What the demo doesn't show you is what happens when an LPN arrives at receiving without a matching ASN. Or when a replenishment task fires for a location that was just manually adjusted by a supervisor. Or when a carrier shows up two hours early and the dock schedule hasn't been released yet. Those aren't edge cases in a real warehouse. They're Tuesday.

The gap between a polished demo and a working operation is where most WMS selections go wrong. The RFP captures feature lists. The demo covers happy-path workflows. Neither one forces the vendor to show you how the system behaves when something breaks. If you don't ask those questions before you sign, you find out the answers during go-live.

Why RFP Processes Miss What Actually Matters

The standard RFP is a checklist. Does the system support wave management? Yes. Does it support LPN tracking? Yes. Does it integrate with your carrier? Yes. Every tier-one vendor checks every box because the boxes are written at a feature level, not a workflow level. You end up with a spreadsheet where every vendor scores 90% and you still don't know which system your receiving team will be cursing six months after go-live.

The problem is that RFPs ask about capabilities, not behavior. A system can support directed putaway and still route product to a full location if the location capacity attributes aren't configured correctly. A system can support cycle counting and still give you no way to prioritize which locations to count first based on exception history. The capability exists. The operational execution depends entirely on configuration depth, exception handling logic, and how much the system can flex without a developer in the room.

Good WMS evaluation asks: what does the system do when something goes wrong, and who has to fix it? That question doesn't show up in most RFPs.

The Receiving Floor Is Where Demos Fall Apart

Ask any vendor to demo an unplanned receipt. No ASN. Unknown supplier. Mixed SKUs on a single pallet. Watch what happens. Some systems require a supervisor override and a manual license plate creation before anything can move. Others let the receiver initiate a blind receipt workflow directly from the RF device. A few lock up entirely until someone calls the help desk. That single scenario tells you more about day-to-day usability than an hour of scripted demo.

The follow-up question matters just as much: where does that exception go after it's resolved? Does it create an inventory record that your cycle count team will find in 60 days? Does it drop into an exception queue that a supervisor has to manually close? Does it silently create a location discrepancy that shows up as a pick-to-zero event three weeks from now? The receiving exception isn't the problem. What the system does with the residue of that exception is the problem.

While you're on the dock, ask about carrier timing. Your dock schedule runs on appointment windows, but carriers show up early, late, and occasionally not at all. Ask the vendor how an early carrier arrival gets processed when the inbound task hasn't been released. Ask what the system does when two trucks arrive simultaneously for the same dock door. Ask whether the dock schedule lives inside the WMS or in a separate yard management module, and what breaks if the two fall out of sync.

Replenishment Logic Under Pressure

Replenishment is where most warehouse operations bleed labor without realizing it. Ask the vendor to show you what happens when a forward pick location hits its minimum quantity threshold during an active wave. Does the system generate a replenishment task automatically? Does the wave pause? Does it re-route the pick task to a reserve location? Does the picker get a message on the RF device or does the task just silently fail?

Then ask what happens when replenishment can't complete in time. If the reserve location for that SKU is also empty, does the system handle a pick-to-zero gracefully, or does it generate an exception that someone manually resolves while the wave sits waiting? Ask how the system prioritizes replenishment tasks when five forward pick locations hit their minimums simultaneously. That's not a rare scenario during peak. It happens on any high-volume outbound shift when the slotting hasn't kept pace with velocity changes.

Task interleaving is worth asking about specifically. Some systems can assign a replenishment task to a picker who is already working in the same zone, reducing the travel cost of the replenishment run. Others treat replenishment as a separate labor pool with no interleaving logic. If your operation is running replenishment and picking simultaneously, the difference in labor cost between those two approaches is real and measurable.

Configuration Depth and Who Controls It

One of the most important questions in any WMS evaluation has nothing to do with features: who can change the configuration, and how long does it take? Ask the vendor to walk you through what happens when you need to add a new zone, change a velocity classification for a SKU group, or modify a wave release rule. Is that something your operations team can do through an admin interface? Does it require a ticket to the vendor's professional services team? Does it require a code change?

This matters because your operation changes constantly. New client programs, new SKU profiles, new carrier requirements, seasonal volume shifts. A WMS that requires vendor involvement every time you adjust a workflow rule will slow you down in ways that don't show up in the implementation timeline but absolutely show up in your operating cost.

Ask to see the admin configuration screens, not just the operator-facing screens. Ask what a supervisor can change without IT involvement. Ask how long a typical configuration change takes from request to live in production. If the vendor pivots away from that question or defaults to talking about their implementation team's responsiveness, that's an answer in itself.

Building Demo Scenarios from Your Own Exceptions

The most useful thing you can do before any vendor demo is pull 30 days of your current WMS exception logs, your supervisor override records, and your manual workaround list. That data tells you what your operation actually looks like, not what the vendor assumes it looks like. Build three or four demo scenarios directly from those exceptions and send them to the vendor a week before the demo. Ask them to show you how their system handles each one.

A vendor who takes that seriously and comes back with a scripted walkthrough of your actual scenarios is worth more of your time. A vendor who redirects to their standard demo path is showing you exactly how the implementation will go: their process, their timeline, their assumptions about what you need.

Specific scenarios that tend to reveal the most about a system's operational depth:

If those scenarios expose gaps, the vendor will tell you the gaps are configurable or covered in a future release. Push for specifics. Ask to see the configuration screen. Ask for a reference customer running that workflow today. Ask what the workaround is if the feature isn't available at go-live. How a vendor handles that pressure in a sales cycle is a preview of how they'll handle it after contract signature.

  • Inbound exception mid-receiving. An LPN arrives with a quantity discrepancy against the ASN. Show the exception workflow from the RF device through supervisor resolution and inventory reconciliation.
  • Pick-to-zero during an active wave. A high-velocity SKU runs out in the forward pick location with 40 open picks still assigned. Show how the wave handles it and what the picker sees.
  • Unplanned inventory adjustment. A supervisor needs to adjust a location quantity outside of a cycle count. Show the audit trail, the inventory impact, and any downstream task effects.
  • New client program setup. For 3PLs: show the full configuration required to onboard a new client, including billing rules, SLA parameters, label formats, and reporting. Ask how long it takes without vendor assistance.

What a Strong Evaluation Process Looks Like

Scripted demos favor the vendor. Scenario-based evaluations favor the operator. The shift is simple: instead of asking vendors to show you their system, ask them to show you your operation running in their system. That requires you to do more work before the demo, but it compresses months of post-go-live discovery into a two-hour session.

A solid evaluation process runs three stages. First, document your actual exception volume and workflow failure points before you talk to any vendor. Second, build your demo scenarios from that data, not from a generic requirements template. Third, score vendors on exception handling and configuration control, not just feature presence.

The operation that signs a WMS contract based on a polished demo and a feature checklist will spend the first six months of go-live discovering what the demo didn't show. The questions are already there in your exception logs. Ask them before the contract, not after.