Confessions of a former demo builder
An ERP demo is a magic show.
We can say that with a straight face because people on our team spent 13+ years on the vendor side of this industry, building the show. Scripting the demos. Rehearsing the flows. Choosing exactly which workflow you'd see and, more importantly, which ones you wouldn't.
None of that is dishonest. It's just sales. Every vendor scripts their demo around the product's strengths, loads it with clean data, and rehearses the happy path until it looks effortless. The workflow that glides across the screen got picked precisely because it glides.
But if you run a $20M distribution business and you're choosing a system you'll live with for a decade, your job in that meeting is different from the presenter's job. Their job is to make you feel confident. Your job is to find out whether you should be.
The way you do that is by breaking the script.
Why the happy path tells you nothing
Think about what actually consumes your team's day. Is it the clean order, in stock, picked correctly, shipped on time? That order takes care of itself in any halfway decent system.
Your team's day gets eaten by exceptions. The count that doesn't match. The return on an order that shipped wrong in the first place. The online order for an item the warehouse can't find. Exceptions are maybe 10% of your volume and 60% of your labor.
The demo, by design, contains zero exceptions. So a standard demo shows you how the system handles the 10% of your operation that was never the problem.
Five requests that break the script
Bring these to your next demo. Ask them politely, and don't accept a slide in place of a live screen.
1. "Show me a cycle count where the count doesn't match the system."
Every system can display a count screen. What you need to see is the discrepancy workflow. Who gets notified, what the adjustment approval looks like, and whether the system helps you find the cause or just papers over the difference.
The discrepancy screen is your inventory team's daily reality. If the presenter has never shown it before, watch how long it takes to find.
2. "Show me what happens when the ecommerce order and the ERP disagree."
Sync conflicts are where inventory trust goes to die. An order exists in Shopify but not in the ERP, or a quantity update failed silently overnight.
Ask to see the conflict surfaced, not just the integration marketing page. A good answer shows you an exception queue and an alert. A bad answer is a diagram with arrows on it.
3. "Process a return on an order that was mispicked in the first place."
This one stacks two exceptions on top of each other, which is exactly why we love it. The customer sends back an item, but it's not the item the system thinks they have, because the original pick was wrong.
Real warehouses deal with this every week. Systems that handle it gracefully tend to handle everything else gracefully too. Systems that choke on it will choke on your Tuesdays.
4. "Now run that same workflow with our part numbers and our units of measure."
Demo data hides friction. Every SKU is tidy, every unit is "each," and nothing has a 40-character part number with embedded revision codes.
Send the vendor a sample of your actual item master before the demo and ask them to load it. Your data drags the friction into the light. If they push back on loading twenty of your SKUs, ask yourself what the implementation will feel like with twenty thousand.
5. "Show me the screen the picker actually sees, on the device they'd actually hold."
Demos happen on big monitors showing executive dashboards, because executives sit in the audience. But the dashboard isn't where accuracy is won or lost. The floor is.
Ask to see the picking screen on a handheld scanner or whatever hardware your team would really use. Small fonts, glare, gloves, and a picker moving fast. That screen determines your data quality far more than any dashboard.
How to read the response
Here's the useful part. You learn as much from how these requests land as from the software itself.
If the presenter handles all five without breaking a sweat, that tells you something real. It means the product has depth beyond the script, and it means this team has stood in front of operators before.
If any request gets a "let me circle back on that," well, that tells you more. One deferral is fine, everyone has gaps. A pattern of deferrals on exception handling means the exceptions live outside the product's comfort zone, and your operation lives inside its exceptions.
One last thing about demo etiquette
Send your requests to the vendor a few days ahead. That might sound like giving away the test, but it isn't.
A vendor who preps thoroughly for your hard scenarios just showed you how they'll behave during implementation. A vendor who received your list and still shows you the canned script showed you something too.
Either way, you walk out knowing more than the audience at the magic show. And when you're signing up for a decade with this system, that's the whole point of being in the room.
