The Demo Was Flawless. Go-Live Was a Dumpster Fire: How to Run a WMS POC That Actually Works

The demo was flawless. Forty-five minutes, and every click landed like a piano note. Orders flowed in from the ERP, waves released on schedule, pickers followed the RF prompts, labels printed, trailers loaded. The sales engineer even smiled through the "any questions?" part. My VP of Operations turned to me afterward and said, "This is it. Let's sign."

Six months later, week one of go-live, I stood in the same warehouse watching a supervisor scribble picks on a clipboard because the RF guns had been queueing for forty minutes. A trailer missed its appointment because the wave release silently dropped 300 orders. Returns from the holiday season sat in a corner for two days because nobody had figured out who owned that workflow. That warehouse was a 380,000-square-foot 3PL facility in the Inland Empire, about 4,000 orders a day at peak, and the WMS contract was $210,000 a year. The demo had nothing to do with it.

I've sat through at least a dozen WMS demos over twenty years of running warehouses and selecting systems. Every single one looked great. Here's the uncomfortable truth: demos are supposed to look great. The demo dataset is clean — SKUs all have the right dimensions, barcodes scan, inventory matches. The workflow follows the happy path — one pick, one carton, one carrier, nothing damaged, nobody short-picked, nobody returns anything. And the sales engineer has rehearsed those clicks a hundred times. They know exactly which buttons to press and which screens to skip. You're not watching the software. You're watching a performance.

A real proof of concept is the opposite of a performance. It's adversarial. You're handing the vendor your mess and asking it to survive.

Here's how I run one now, after getting burned.

First, the POC runs on your data, not theirs. Export two weeks of your actual orders — all of them, including the ugly ones — and a real SKU master, including the items with wrong dimensions and missing barcodes, because those exist in every warehouse I've ever managed. If a vendor balks at loading your data and insists on using their sandbox dataset, that's your first red flag. A WMS that only works with clean data is a WMS that doesn't work.

Second, write the acceptance criteria before the POC starts, and weight them toward the abnormal branches. The normal flow will pass. It's always the exceptions that kill you: short picks, damaged receipts, wave releases that need to be rebuilt mid-shift, split shipments, returns without an RMA. I insist on scripting at least 60% of the acceptance tests around exceptions. Ask the vendor's team to run a wave release with a carrier cutoff in ten minutes while two orders get short-picked. Watch what happens. That's Tuesday in a real warehouse.

Third, time-box it. Two to four weeks, hard stop. Any longer and it becomes a shadow implementation where the vendor embeds consultants, builds custom workarounds, and calls it a "successful POC." You want a representative slice, not a parallel universe. If four weeks isn't enough for the vendor to show the core workflows on your data, the product is too heavy for you. Walk away.

Fourth, put the integration surface in scope — no exceptions. The WMS demo always shows a tidy little "ERP integration" box on the architecture slide. In reality, that's where implementations die. Your POC has to include the actual handshake: purchase orders coming down from the ERP, shipments and inventory going back up, and carrier shipping labels printing from the pack station with real rate shopping. I've seen a go-live delayed eleven weeks because the ERP's item master used a different UOM convention than the WMS and nobody mapped it until week three of testing. That cost the company about $60,000 in extended consulting alone. Test the seams early, because that's where the leaks are.

Fifth, require the vendor to expose the API documentation and the error logs. This one surprises people. The demo shows you the UI. The operations team lives in the logs. During the POC, something will fail — a label print job, an API call to the carrier, a sync to the ERP. Ask to see how you find out what happened. Is there a readable error log? Can your IT person hit the API without calling the vendor's support line? A vendor that treats its API docs as a premium add-on is telling you exactly what support will feel like after go-live. Believe them.

Now, the three traps. I've watched these blow up go-lives more than anything else.

Trap one: abnormal flows were never tested. This is the big one. The receiving dock gets a shipment with 200 cartons damaged by rain. A picker drops a carton and the product is unsellable. An order gets cancelled after the wave already released. In every postmortem I've been part of, the "we never tested that" list is three pages long, and it's all exceptions. Demos never show them. Most POCs skip them too, because they're awkward to script. Script them anyway. Your warehouse runs on exceptions; your POC should too.

Trap two: data migration volume was never stress-tested. The POC usually loads a few hundred SKUs and runs fine. Then go-live arrives with 18,000 SKUs, six months of open orders, and three years of customer profiles to migrate, and the sync jobs take nine hours instead of nine minutes. I watched a facility miss its entire Monday ship schedule in October — the start of peak season — because the initial inventory upload locked the tables and orders couldn't release. Run a full-volume load test during the POC. It takes one weekend and saves you from the worst kind of surprise.

Trap three: nobody called the reference customers. Vendors hand you a list of glowing references, and half of buying teams never call. Call all of them. But don't ask "are you happy with the system?" Ask specifics: "How many of your exception workflows did you have to customize?" "What broke in the first month of go-live?" "How long does a support ticket take to get an actual answer?" One reference call saved me from a seven-figure mistake in 2019 — the warehouse manager told me their go-live had been delayed five months and they'd needed two full-time vendor consultants on-site for a year. The vendor's sales team had described that same customer as a "smooth implementation."

So here's the short version — the acceptance checklist I hand to vendors before a POC begins:

Run it on my real orders and my real SKUs, messy data included. Cover the exceptions, not just the happy path — short picks, damages, rebuilt waves, returns. Finish in four weeks or less. Include the ERP handshake, the carrier labels, and the API docs in scope. Show me a readable error log when something fails. Load-test at full volume. And let me call your references with specific questions.

If a vendor pushes back on any of this, that's not a negotiation problem. That's information.

What I'd do tomorrow

If you're evaluating WMS vendors right now, do one thing this week: pick the three ugliest exceptions from last month — the rain-damaged receipt, the rebuilt wave, the return nobody knew how to process — and write them up as test scripts before the next vendor call. Hand them to the sales engineer and say, "Show me these in the POC." The look on their face will tell you everything about the product. And it'll cost you nothing, which is the cheapest insurance in this whole business.