How to read an ERP demo without being sold to

A vendor demonstration is designed to impress you. That is not a criticism; it is the purpose of the exercise, and a vendor who ran a demo that did not impress would be doing his job badly.

The problem is watching one without a scenario of your own. Then you spend ninety minutes assessing how good the presenter is while believing you are assessing how good the system is. Those two things correlate weakly, and one of them is not going to run your business.

This page inverts the direction. You supply the scenario; the product is what gets examined.

Why every system looks excellent in a demo

Three structural reasons, none of which requires bad faith from anyone in the room.

Reason	What it conceals
The demo environment has every module enabled	What you saw may not be in your quotation
The data was prepared in advance and is clean	Items, customers and tax codes were correct before you arrived
The click path is rehearsed	Every step has been run dozens of times, and anything that failed was removed from the script

Put together, a demo shows you what the product does when everything goes right. You are going to spend the next five years in the other case.

Rule one: send your scenarios a week ahead

Write three scenarios, send them seven days before the meeting, and ask for them to be executed in front of you.

The wording matters. Ask for them to be performed, not explained: “Raise a purchase order for two items. Receive only one of them. Enter the supplier invoice for the full quantity. Show me what the system does.”

Three scenarios of that kind reveal more than a full-day presentation. Choose them like this:

One that leaves the happy path. A partial receipt, or a return after the invoice has been issued. Every product handles the clean case; the differences live in the exceptions, and the exceptions are what your staff will hit in week two.

One that is specific to your business. Your pricing structure, a dual unit of measure, a maintenance contract, a project with retention. If the answer here is a workaround, you want to know now rather than in the design workshop you have already paid for.

One deliberate mistake. Enter a quantity larger than the order allows and watch what happens. This is the most revealing of the three, because the expensive failures in ERP are rarely things the system cannot do. They are things the system permitted that it should have refused.

Eight questions that change the meeting

Ask them in these words, and write the answers down in these words.

Question	What it exposes
Show me this screen with our data	Whether the product fits our case or the demo’s case
Which numbered line in the quotation covers this module?	The gap between what I saw and what I am buying
Is this standard, or is it a customisation?	A cost paid once versus a cost paid at every upgrade
Who performs this at our end — our staff or your consultant?	The running cost after go-live
Show me this report printed in Arabic	The difference between shipping Arabic and promising it
What happens if the user gets this wrong?	The controls, which matter more than the features
How many customers in my country are on this exact version?	Local maturity rather than global logo count
Who owns my data, and how do I extract it?	The cost of leaving, priced before you arrive

The last one is always forgotten and always paid for, usually in year three when a migration quote arrives that is larger than the original licence.

Four answers to write into the minutes

“That’s definitely possible.” This is not an answer. It is a promise with no price attached. The acceptable forms are three: standard, configuration, or customisation at a stated number of hours.

“We’ll show that in the next session.” Once is fine. Twice on the same scenario is a real gap being managed rather than a scheduling problem.

A demo on a version you are not buying. Ask for the version number on screen and compare it with the version in the quotation. Features move between editions, and the edition in the proposal is frequently one tier below the edition being demonstrated.

Stepping over your scenario to a better-looking feature. You asked for a partial receipt and you are being shown an analytics dashboard. The redirection is the answer: there is something in the partial receipt.

What to do in the hour afterwards

Write it the same hour, not the next day. Memory of a demo degrades faster than anyone expects, and by tomorrow you will have merged this vendor with the last one.

• Which of my three scenarios were actually executed in front of me.
• What was promised but not shown, in the exact wording used.
• Every module that appeared on screen, and against each: is there a line for it in the quotation?
• The version number displayed.

Then send that page to the vendor and ask for written confirmation. A vendor who confirms it has earned a second round. A vendor who avoids confirming it has answered your question.

Comparing three demos

Do not compare your impressions of three meetings. Compare the behaviour of three systems on the same scenario.

An impression is affected by the presenter’s skill, the quality of the video call, and whether the meeting was at nine in the morning or at four after two others. System behaviour on a defined scenario is affected by none of those things.

Build the table yourself: a row per scenario, a column per product, and one word in each cell — done, done with customisation, or not done. Nine cells decide a decision that a hundred slides could not.

Where to go from here

The scenarios you send are written out of the cycles themselves: the procurement cycle, order to cash, inventory and costing, and the ledger and the close. Someone who understands the cycle writes a scenario that exposes something; someone who does not writes a general request and receives a beautiful presentation in reply. The reading order is on the learn ERP page.

And most of each product’s limits are already known before you sit down. They are set out product by product in the systems comparison. Read the system’s page before its demo, not after it.