- Mandate the same scenarios for each vendor to ensure the demonstrations are comparable.
- Test exceptions and clearly distinguish between standard, configuration, extension, development, and workarounds.
- Require proof for every critical capability and score immediately after each scenario.
- Use a weighted grid that includes evidence, gaps, and risks rather than a simple average.
An ERP demo is not a stage performance. It is a decision-making test. If the vendor alone chooses the scenario, the order of the screens, and the cases presented, you are primarily evaluating their ability to give a good presentation.
To properly evaluate an ERP demo, impose the same scenarios on every vendor, test the exceptions that matter to your operations, and demand proof for every capability deemed critical.
In short: how do you evaluate an ERP demo?
Before the demo, define your critical scenarios, exceptions, weighted criteria, and expected proof. During the demonstration, have your scenarios executed in the ERP, distinguish between standard features and configuration or development, document workarounds, and score immediately. After the demo, compare all solutions using the same grid.
A sales claim should never receive the same score as a capability that has been actually demonstrated.
1. Start with your scenarios, not a feature list
A feature list often produces a series of "yes" answers. A scenario forces the vendor to show how the work actually gets done.
For example: receiving an urgent order, checking stock across multiple sites, reserving inventory, producing what is missing, shipping partially, and then invoicing the customer. The scenario reveals the steps, dependencies, and trade-offs that a simple "order management" checkbox does not show.
2. Give the same scenario to every vendor
If every vendor or integrator does their own demo, you are comparing different presentations. To establish a basis for decision-making, impose the same processes, starting data, and expected results.
This discipline must begin with the ERP RFP so that vendors know what will be evaluated.
3. Have them demonstrate the exceptions
Standard processes are generally the easiest to show. The real gaps appear in the exceptions: partial orders, returns, substitutions, stockouts, credits, bill of material changes, out-of-threshold approvals, or inter-site transfers.
Choose the exceptions that are already costing your organization time. They often have more decision-making value than ten standard functions.
4. Ask what is standard, configured, extended, or developed
For every important capability, explicitly ask if it is part of the standard product, a configuration, an extension, a custom development, or a workaround.
These categories do not carry the same cost, maintenance risk, or impact on future updates.
5. Count the actual steps
Do not just score whether the process is possible. Look at how many screens, clicks, context switches, and validations are required.
A process used 500 times a day deserves different attention than a monthly operation. Frequency should influence the weight given to ergonomics.
6. Use representative data
A demo becomes much more useful when the vendor is required to work with examples that resemble your business: products, sites, units of measure, stock levels, customers, suppliers, or accounting structures.
You don't need to transfer sensitive data. The goal is to prevent a demonstration built solely around a perfect environment prepared by the salesperson.
7. Test critical integrations
For every important interface, ask what is native, what uses an API, what requires a third-party tool, and who will be responsible for the integration.
Also verify whether the integration is included in the proposal or simply presented as technically possible.
8. Evaluate the integrator at the same time as the ERP
The demo also shows the quality of the team that could carry out the project. Observe whether they understand your operations, recognize the product's limitations, ask good questions, and know how to explain trade-offs.
Evaluate the solution and the integrator separately. You will then be able to compare ERP proposals without conflating software quality, team, price, and risk.
9. Demand proof when the answer is "yes"
A critical capability can be validated by several types of proof: live demonstration, visible configuration, product documentation, architecture, comparable reference, written commitment, or contractual provision.
The more critical the capability, the less a verbal answer should suffice.
10. Score immediately after each scenario
Do not put off scoring until the end of the day. Impressions quickly blur between vendors.
Use a simple scale, for example 1 to 5, with a clear definition for each level. Add a column for proof and another for gaps or questions to confirm.
11. Use a weighted grid, not a simple average
Not all criteria carry the same weight. A regulatory requirement or a core production process can be a deal-breaker, even if the solution achieves an excellent overall average.
A possible structure: functional fit 20%, architecture 10%, integrations 10%, data 10%, integrator 12%, implementation risk 8%, adoption 5%, total cost 10%, contractual terms 5%, plus criteria specific to your business.
The PlanAxion grid allows you to formalize this type of comparison.
12. Finish with a list of documented gaps
At the end of the demonstration, every unproven item must be turned into an action: a question to confirm, a follow-up test, a document to receive, a proof of concept, or a commitment to include in the proposal.
Assign an owner and a deadline to every critical gap. No important point should simply disappear just because the demo is over.
25 questions to ask during an ERP demo
- Can you run this scenario from start to finish?
- Is this capability standard?
- What configuration is required?
- Is an extension required?
- Is custom development required?
- Which part relies on a third-party product?
- What happens in this exception scenario?
- How many steps does the user have to perform?
- Can these steps be automated?
- How are approvals managed?
- How does this feature behave across multiple sites?
- How do you manage rights and roles?
- How does the ERP integrate with our critical system?
- Who builds and maintains this interface?
- Is it included in the estimate?
- What data needs to be prepared?
- Which historical data can be migrated?
- How are errors detected?
- Which reports are standard?
- What product limitations should we be aware of?
- Have you delivered this scenario in our industry before?
- Which part of the demonstration is customized for us?
- What assumption are you making here?
- Can you provide documentation for this answer?
- What do we still need to validate before considering this requirement covered?
A demo is not enough to select an ERP
A demonstration is just one of many sources of evidence. The final decision must also incorporate the RFP, references, the integrator, architecture, data, total cost, risks, and commercial terms.
PlanAxion supports organizations on the client side to define scenarios, control demonstrations, document evidence, and transform results into a comparable decision.
Frequently asked questions
Who should participate in an ERP demo?
The owners of the affected processes, IT, the project manager, and the decision-makers who will need to approve major trade-offs. It is not necessary for the entire organization to attend every session.
How many solutions should be invited to demonstrate?
Vendors reaching this stage should have already passed a pre-selection process. The goal is to compare a few credible options in depth rather than multiplying superficial presentations.
How long should an ERP demo last?
The duration depends on the number of critical scenarios. A good demo is organized by process and reserves enough time for exceptions, questions, and scoring.
Should the vendor choose the demo content?
It may highlight certain differentiating elements, but critical scenarios and evaluation criteria should be defined by the client.
How do you compare two ERP demos?
Use the same scenarios, criteria, and scoring scale. Also, document the evidence, gaps, and assumptions for each solution.
Is one demo enough to choose an ERP?
No. It must be combined with an analysis of the proposal, the integrator, total cost, risks, references, and contractual terms.
What is the difference between a demo and a proof of concept?
A demo shows how the product handles defined scenarios. A proof of concept generally explores a specific risk in greater depth, using configuration, data, or integration that is closer to the client's actual reality.
Primary source: PlanAxion’s client-side ERP selection method. See also ERP selection grid, ERP request for proposal and Independent ERP selection.
