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

The requirements went out as a feature list. Every vendor answered yes. The demos were run by the vendors, 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 actually want is permission.

You can run this yourself. I would rather you did, honestly, because the people who use the system every day are better at judging it than I am. What you need is a process that does not hand the steering wheel to the people selling.

The demo is not the decision

A vendor demo is a performance. The team giving it has run it hundreds of times. They know which screens look good, which ones to move past quickly, and how to answer a hard question with a story about another customer.

None of that is dishonest. It is just what a demo is.

The problem is that most buyers treat the demo as the evaluation. It is the last twenty percent. The evaluation happens when you write down what your warehouse actually has to do, before anyone has shown you anything.

Write requirements as outcomes, not features

"Barcode receiving" is not a requirement. Every product on your list will say yes to it.

This is one:

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

Now the yes means something. A vendor either shows you that flow or starts explaining.

The test I use: could two vendors both answer yes and mean genuinely different things? If so, it is a feature, not a requirement. Rewrite it until a yes commits them to behavior 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 was on the list and nobody remembers.

Cap your must-haves

Here is the failure I see most often, and it is not subtle.

A team marks 140 of 200 requirements as required. The vendors, sensibly, say yes to nearly all of them. The scores come out within two points of each other, the requirements have told you nothing, and the decision falls back to whoever gave the best demo.

Thirty is my cap. Not a magic number, but a forcing function. A must-have should mean you would walk away from an otherwise excellent system without it. Most teams find that eight or ten of their must-haves came from a vendor pitch rather than from their own floor.

When you cut the list to thirty, the scoring starts separating vendors again. That is the whole point.

Know which kind of vendor you are talking to

There are four, and they are not competing for the same buyer.

Your ERP vendor's own warehouse module. Tight integration by definition, usually the least capable on the floor. Put it on the list as the baseline even if you expect to beat it. It tells you what the gap is actually worth.

Ecosystem add-ons. Products built for your ERP specifically, sold through its partner channel, often by a company that does nothing else. The integration is their entire business, so it is usually the best-tested part of the product. For most mid-market operations, this is where the winner comes from.

Independent mid-market WMS. Runs with many ERPs through connectors. Deeper warehouse functionality, more configuration, more implementation effort. The connector to your specific ERP version is the thing to verify hardest, because it is one of twenty they maintain rather than the only one.

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.

The best single place to build a longlist is your ERP's annual conference sponsor list. The warehouse vendors who pay for a booth are the ones with enough customers on that ERP to justify it.

Script the demo yourself

Same scenarios, every vendor, sent ten business days ahead, built from your operation. Ask them to load a small slice of your data. Twenty items is plenty.

Then 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 does not.

Keep some steps back for the day itself. When the receiver scans the wrong purchase order, when does the system catch it? Can an operator skip the item scan, and who approves that? Ask the vendor to break the integration on purpose and show you where the failed transaction lands and whose name is on it.

The warehouse manager has to be in that room. Non-negotiable. That person spots the workaround the presenter is gliding past.

Price five years, not year one

Year one is almost always the most expensive year and the only one anyone quotes.

The lines that get left out are predictable. Your own team's hours during implementation, which routinely run double what the vendor quoted for theirs. Handheld replacement in year three. The annual escalator on support. The productivity dip in the first sixty days after go-live, which is real whether or not you put a number on it. The allowance for re-integrating when you upgrade your ERP inside the term.

Add those and the ranking changes more often than not. I have watched a cheaper-looking quote lose by sixty thousand dollars once someone counted the hours.

Where I would get help, and where I would not

If you have one warehouse, a few thousand SKUs, and a team that can spend a few hours a week on this for a couple of months, you do not need me. The process above is the whole job. It takes fourteen to eighteen weeks alongside a day job, and anyone promising six weeks is selling something.

I packaged the workbook and demo scripts I had been rebuilding for every client into a Selection Kit, because it was silly to keep making them from scratch. 212 requirements, the scoring model, the five-year cost model, the demo scripts with the traps left in.

Get help when the operation is genuinely complicated, when there is real disagreement inside the building about what the problem is, or when you have quotes in hand and something does not smell right and you cannot say why.

That last one is worth an outside opinion. The rest of it you can do, and you will end up understanding the decision better than any report I could write for you.