Most of the warehouse software selections I get called into are already decided by the time I show up. Not signed. Decided.

The requirements went out as a feature list and every vendor answered yes. The demos ran on the vendors' data, in the vendors' order. By the time anyone asks me to look, the team has a favorite and a quote, and what they want from me is permission.

You can run this yourself, and I'd rather you did, because the people who'll use the system every day judge it better than I can. What you need is a process that doesn't hand the steering wheel to the people selling.

The demo isn't the decision

A demo is a performance by a team that's given it hundreds of times. They know which screens look good and which to move past quickly, and how to answer a hard question with a story about another customer. None of that is dishonest. It's what a demo is.

Most buyers treat the demo as the evaluation. It's the last twenty percent. The evaluation happens when you write down what your warehouse has to do, before anyone's shown you anything.

Write outcomes, not features

"Barcode receiving" isn't a requirement. Everything on your list will say yes to it. This is one:

Receive an item that isn't on the purchase order into a hold status, visible to a supervisor, without blocking the rest of the receipt.

Now a yes means something. The vendor either shows you that flow or starts explaining. My test: could two vendors both say yes and mean different things? Then it's a feature. Rewrite it until a yes commits them to something you could watch on a screen.

Write down why each one matters, too. Not for the vendor. For you, in week nine, when someone asks why blind receiving made the list and nobody remembers.

Cap the must-haves at thirty

This is the failure I see most. A team marks 140 of 200 requirements as required, the vendors sensibly say yes to nearly all of them, and the scores land within two points of each other. The requirements told you nothing, so the decision falls back to whoever gave the best demo.

Thirty isn't magic. It forces the argument. A must-have should mean you'd walk away from an otherwise excellent system without it, and most teams find eight or ten of theirs came from a vendor pitch rather than their own floor. Cut to thirty and the scores start separating vendors again.

Know which kind of vendor you're talking to

Your ERP's own warehouse module. Integrated by definition and usually the least capable on the floor. Put it on the list as the baseline anyway, because it tells you what the gap is worth.

Add-ons built for your ERP. Sold through its partner channel, often by a company that does nothing else. The integration is their whole business, so it tends to be the best-tested part. For most mid-market operations, the winner comes from here.

Independent mid-market WMS. Connects to many ERPs, with deeper features and more configuration. Test the connector to your exact ERP version hardest, because it's one of twenty they maintain.

Enterprise WMS. Built for distribution centers with automation and labor management. If one is pitching you and you have twelve people on the floor, ask why.

For a longlist, start with your ERP's annual conference sponsor list. Warehouse vendors who pay for a booth have enough customers on that ERP to justify it.

Script the demo yourself

Same scenarios for every vendor, sent ten business days ahead, built from your operation, with a small slice of your data loaded. Twenty items is plenty. Put an exception in every scenario, because exceptions are where systems differ and where projects fail. A clean receipt looks the same everywhere. A short shipment with an unexpected item on the truck doesn't.

Send every step. I used to hold a few back as gotchas and stopped, because over a video call they just get you "we'd need to configure that." Keep the commentary to yourself instead: what a good answer sounds like and where the usual dodges go.

Then ask what a script can't cover. If the receiver scans the wrong purchase order, when does the system catch it? Break the integration on purpose and show me where the failed transaction lands and whose name is on it.

Run two sessions. Six core scenarios for everyone, then a second whose agenda comes from what you saw. Three hours in one sitting is too long to score well. And the warehouse manager is in the room, no exceptions, because that's the person who spots the workaround the presenter is gliding past.

Price five years

Year one is usually the most expensive and the only one anyone quotes. What gets left out is predictable: your own team's hours (which routinely run double what the vendor quoted for theirs), handheld replacement in year three, the support escalator, the productivity dip in the first sixty days, and re-integration when you upgrade your ERP mid-term. Add those and the ranking changes more often than not. I've watched a cheaper-looking quote lose by sixty thousand dollars once someone counted the hours.

When to get help

With one warehouse, a few thousand SKUs and a team that can give this a few hours a week for a couple of months, you don't need me. The process above is the whole job, and it takes fourteen to eighteen weeks alongside a day job. Anyone promising six is selling something.

I got tired of rebuilding the same workbook and demo scripts for every client, so I packaged them as a Selection Kit: 216 requirements, the scoring model, the five-year cost model, an ROI calculator, and the demo scripts with the commentary that doesn't go to the vendor.

Get outside help when people inside the building disagree about what the problem is, or when you have quotes in hand and something smells off and you can't say why. That last one is worth a second opinion. The rest you can do, and you'll understand the decision better for having done it.