WMS checklist: what to ask, what to test, before you sign

Questions for yourself first

How many doors do you sell through today, and how many next year. One channel can live on an inventory app; two cannot.

How many people move stock. One person can hold the building in their head. Two need a shared record.

What do you sell. Lots and expiry, case conversions, kits, marketplace stickers: each one is a feature you cannot skip and a feature someone else can.

Where the money is. If overselling costs you refunds and marketplace metrics, available to promise is the feature. If shrinkage costs you, it is the ledger and the counts. If labor costs you, it is scan-first and directed work.

Who owns the books. If an accounting tool or an ERP already does, you want a WMS that feeds it, not one that replaces it.

Questions for the vendor

Is a balance a stored number or a computed one. Can a user type over it. If yes, who, and what is written down when they do.

Show me the movement that made this number change. On a real screen, not a slide.

What is available to promise here, exactly. Does it exclude the dock, damaged and quarantine. Does it subtract allocations. Is it computed on the server or in the browser. Can it be reserved per channel.

What happens when a picker scans the wrong product. What happens when two channels sell the last unit in the same minute.

How does a return get back on the shelf, and what row does it write.

Which system is the source of truth for cost. If the answer is “ours,” ask how it closes the books. If the answer is “your accounting system,” good.

How do I get my data out. Every table, as files, without asking.

When did each feature you are showing me ship. A changelog with versions and dates is a good sign. A roadmap slide is not.

Five tests to run on the trial

1. The overwrite test. Try to change a quantity without a document. If you can, the record is a belief.

2. The last-unit test. Put one unit of a product on two channels. Sell it on both within a minute. One order should allocate; the other should be short by name, and the second channel should already have seen zero.

3. The wrong-scan test. At pick, scan a lookalike product, then a product whose barcode starts with the same digits. Both should be refused. At pack, try to close a box without scanning every line.

4. The count test. Count a location short by one. The variance should require a reason, the approval should write an adjustment row, and the product’s history should show that row with your name on it.

5. The replay test. Ask for the movement history of one product from day one and add it up yourself. It should equal what the screen shows. If the vendor cannot give you the history, the screen is a number nobody can check.

Signs to walk away

A demo catalog and no way to load yours. A quantity field on the product page. “Available” and “on hand” as the same number. Cost and physical stock in the same system with no way to separate them. No changelog.

How DockingWare answers the five tests

DockingWare has no quantity field to type over; corrections go through a cycle count with a mandatory reason. Allocation is piece-exact on one ledger, and available to promise excludes the dock, damaged and quarantined stock and is published per channel after every movement. Scans must match exactly; a prefix never verifies. Every movement carries a user, a time, a bucket and a reference, and a nightly job replays every row and compares it with the stored balance so the record is checked without you asking. Every feature on the public changelog names the version it shipped in. Run the tests on a trial and tell us if any of that is not true.