What a demo does not show you when choosing inventory software
The same thing happens in most software selection processes: four vendors demo, all four look impressive, and the decision comes down to price or to who felt more reassuring. Two years later, when the conversation turns to why the system did not meet expectations, almost none of the problems that surfaced were things a demo could have shown. In this article I set out five things a demo does not show but that you will meet every day after go-live — and how to test each of them during the demo.
The demo runs on its own data
Data in a demo environment is clean: product codes are unique, barcodes match, unit definitions are consistent, and history is complete. None of that is guaranteed in your data.
What actually happens is this: the same product was opened under two different codes, some barcodes came from the supplier and collide, carton and unit measures got mixed in some records, and part of the movement history from three years ago is missing. Under those conditions no report on the demo screen looks the same.
The way to test it is simple: ask for the demo on a sample from your own product list. A real slice of five hundred items shows, at demo stage, which fields will come out empty and which matching will have to be done by hand. A vendor who will not provide that, or who says 'we will handle it during implementation', is leaving the most expensive part of the job until after the contract.
The real question: where is this number calculated
You see a turnover figure on screen. The question is where that number was produced. There are three possibilities and they lead to three different outcomes.
First, the number was calculated by a defined procedure in the database. In that case, asking the same question twice returns the same answer and the calculation can be audited. Second, it was calculated by a formula inside the reporting tool; then the formula can vary from report to report and two screens can show different numbers. Third, it was produced in the application layer inside code; that is the most fragile, because seeing the calculation means reading source code.
The way to test it in a demo is to ask: 'Can I have the formula for this number and which table it comes from, in writing?' If the answer is slow in coming, or is 'the system calculates it', you will live with the same uncertainty after go-live.
What happens when the past changes
In retail, cost correction is the rule, not the exception. The freight invoice arrives three weeks after the goods, the supplier deducts a price difference, a return is posted against a past batch.
The critical question: does that correction change historical reports, and if it does, is anyone told? Some systems post the correction backwards silently; last month's margin changes overnight and nobody notices. Others never post it at all; then the past stays wrong instead.
The right behaviour is neither: the correction is written as a separate movement type, the period it belongs to and the date it was processed are held in two different fields, and when the report is re-run the reason for the difference can be seen line by line. To test it in a demo, have an expense added to a past purchase and watch what the report does.
Who owns the definition
Once the system is live, this will certainly happen: two departments see different numbers for the same metric and an argument starts. That is unavoidable; what matters is how the argument ends.
In an implementation with a definition dictionary, it ends in five minutes: you look at the dictionary, see which screen uses which definition, change the definition if needed, and the change propagates everywhere. Without a dictionary the argument repeats every month.
The question to ask in the demo: 'Where do the metric definitions live, who can change them, and what happens to historical reports when they change?' The answer to that tells you more about whether the system will still be trusted in two years than any screen in the demo.
The count and the field
The most used part of inventory software is the part that runs in the warehouse and the store, not in the office. Despite that, most demos are given through desktop screens.
There is no network everywhere in a warehouse. Signal drops between racks, in the cold store and in basements. What happens when the connection breaks — whether the count stops, whether records are held on the device, and what happens when the connection returns — has to be asked in the demo. 'Strengthen the Wi-Fi' is not an architectural answer.
The second question is sync behaviour: what does the system do if the same scan is sent twice? In an app that works offline this situation occurs as a matter of course; a sync that cannot deduplicate quietly inflates the count result.
When not to buy software
If the problem you have is process rather than data, software will not solve it. If counts happen twice a year and nobody reviews the variance report, a new system will show the same report on a nicer screen.
In the same way, if product codes have not yet been deduplicated, starting an implementation is premature. That work can be handed to the vendor, but someone on your side has to decide: only the person who knows the product can decide which code survives.
The third case is capacity. Installation needs someone on your side who knows the processes and works alongside our team. Without that person the project is completed technically and never gets used.
What to do
Ask for the demo on a slice of your own data. A decision taken without seeing which fields come out empty leaves the most expensive part of the work until after the contract.
Ask three questions in writing: where is this number calculated, how are historical corrections posted, and where does the definition live. A vendor with written answers to all three is a safer choice even with fewer screens.
Do not judge the field side from a desktop. Ask about offline count behaviour and what happens to a repeated scan; those two questions decide the years you will spend in the warehouse.