A standard ERP demo is a rehearsed performance. The data is clean, the scenarios are chosen by the vendor, and the presenter has run this script hundreds of times. Nothing about that is dishonest — it is simply the wrong instrument for making a decision you will live with for a decade.
These thirty-five questions are designed to surface what the script conceals. They are grouped by category, each with a note on why it matters and what a substantive answer sounds like. Send your scenarios in advance, put your actual users in the room, and score against these rather than against impressions.
Before the Demo: Set the Rules
• Send three or four real scenarios in advance, drawn from your business and including at least one genuinely awkward case.
• Insist on data resembling yours — your item structure, customer types and document volumes. Clean fictional data hides performance and usability problems.
• Put daily users in the room, not only management. They evaluate whether Tuesday’s job gets faster; management evaluates strategy. Both scores matter.
• Give every vendor identical scenarios so the comparison means something.
• Score during the session, not from memory afterwards. Impressions fade and merge.
• Allocate at least half a day per finalist. A ninety-minute demo shows you the highlights reel.
Functional Depth (Questions 1–8)
21. Show us this exact process, end to end, using our scenario. Not a similar process. Watch for redirection to a prepared example.
22. What happens when this goes wrong? Show us a mis-picked order, a wrong-period posting, a partial return. Vendors rehearse the happy path; correction and reversal is where daily life actually happens.
23. Which parts of what you just showed are standard, and which required configuration or custom work? The demo environment is often heavily prepared.
24. How does the system handle our specific edge case? Bring the one your current system cannot do.
25. What is included in the quoted price, and what is a separate module? Demos routinely feature modules outside the proposal.
26. Show us the same transaction from the perspective of a different role. Reveals whether permissions and views genuinely work as claimed.
27. What can this system not do that competitors can? An honest vendor names something. A vendor who claims nothing is either uninformed or evasive.
28. How many of your customers use this specific module in production? New modules are demonstrated long before they are proven.
Usability and Adoption (Questions 9–14)
29. Let one of our staff attempt this task with minimal guidance. The most informative ten minutes of any demo.
30. How many clicks and screens does our highest-volume daily task take? Count them. Multiply by daily volume. That is your real productivity impact.
31. Show us the mobile experience on a phone, not a tablet, and ideally on the actual device warehouse or field staff would use.
32. How does the system perform with a fully populated database? Demo environments are small and fast.
33. What does the interface look like for an occasional user who logs in twice a month to approve something?
34. How long do your customers report it takes staff to become genuinely productive?Then verify this with references rather than taking the answer at face value.
Data and Reporting (Questions 15–19)
35. Build one of our actual reports, live, now. Bring a real report you produce monthly. This single request separates capable reporting tools from ones requiring a consultant for every change.
36. Can a business user create a report without IT or a consultant? Have them demonstrate it, not assert it.
37. How do we get data out in bulk — for analysis, for audit, for a future migration?
38. What does data migration from our current system involve, and who does it?Establish scope and ownership now, not in month six.
39. Show us the audit trail for a transaction. Who changed what, when, and can it be reconstructed? Critical for finance and for regulated sectors.
Integration (Questions 20–24)
40. Which of our existing systems do you connect to natively, today? Get the list in writing. “Possible via API” is not a connector.
41. Show us a live integration running, not an architecture diagram.
42. What are the API limits, and what happens when we exceed them? Overages frequently trigger a higher pricing tier.
43. What happens when an integration fails? Silent failures that nobody notices for a week cause more damage than visible outages.
44. Who maintains the integration when either system updates? The answer determines an ongoing cost you are probably not budgeting.
Technical and Upgrades (Questions 25–28)
45. How often do updates happen, how much notice do we get, and can we test first?For cloud ERP this shapes your operating rhythm permanently.
46. What happens to our configuration and extensions when the core updates? The question that predicts whether upgrades become projects.
47. Do we get a sandbox environment, and is it included? Essential for testing and training; frequently charged separately.
48. What are your contractual uptime commitments and remedies? Ask for the service level document, not the marketing figure.
Implementation and Partner (Questions 29–32)
49. Who specifically will work on our project? Names and CVs. The people in the sales meeting are frequently not the people who arrive at the first workshop.
50. How many implementations have you completed for companies of our size in our industry, and may we speak to three of them? Hesitation here is the whole answer.
51. What is a realistic timeline for a business like ours, and what has caused overruns on similar projects? A vendor who has never seen an overrun has not done many implementations.
52. What do you need from us, in hours per week and from which roles? Forces the internal cost into the open, where it belongs.
Support and Commercials (Questions 33–35)
53. What happens when production is down at month-end? Response times, escalation path, and whether support is available in your timezone.
54. Quote us total cost for three years including implementation, migration, integrations, training, sandboxes and expected renewal increases — and list everything excluded. The clarity of this answer predicts the whole relationship.
55. If we leave in four years, what exactly do we get back, in what format, how quickly, and at what cost? Ask before signing. Afterwards, you have no leverage.
| The three questions to ask if you only have time for threeShow us this failing, not working — a mis-pick, a wrong posting, a partial return.Which of your customers at our size in our industry may we speak to?Total three-year cost including everything, plus a written list of exclusions. |
Answers That Should Concern You
| What they say | What it usually means | Follow up with |
| “That can be customised.” | It is not standard functionality | What does it cost, who maintains it, what happens at the next upgrade? |
| “That’s on the roadmap.” | It does not exist | Score it as absent. Ask what exists today. |
| “Our partner handles that.” | It is outside the quoted scope | Which partner, what cost, is it in this quote? |
| “Nobody has ever asked for that.” | Their customers do not resemble you | Which of your customers most resembles our business? |
| “We’ll get back to you on that.” | Sometimes fair, often avoidance | Set a deadline and record whether it is met. |
| “Let me show you something related.” | Redirection away from a gap | Return to the original question immediately. |
| “Everyone in your industry uses us.” | Marketing, not evidence | Name three we can call. |
| A confident answer with no demonstration | Untested claim | Show us. Now. |
Scoring the Demo
Score during the session, on a shared sheet, with each panel member scoring independently. Discuss afterwards — the disagreements are where the real information is.
| Category | What you are scoring | Suggested weight |
| Functional fit | Did it handle our scenarios without workarounds? | High |
| Usability | Could our staff do the task? How many clicks? | High |
| Reporting | Could they build our report live? | Medium to high |
| Integration | Native connectors demonstrated, not described | Scale to your needs |
| Partner credibility | Comparable references, named consultants, honest answers | High |
| Transparency | Did they acknowledge limitations? | Medium — a strong signal |
| Commercial clarity | Complete three-year quote with exclusions listed | Medium |
Mark must-have requirements as pass or fail separately from the total score. A failed must-have eliminates a vendor regardless of how well they scored elsewhere — otherwise a strong overall number will talk you out of a hard requirement, which is one of the most common and most expensive selection errors.
After the Demo
56. Debrief within a day, while it is fresh. Compare independent scores before discussing.
57. Send written follow-ups for anything unanswered, with a deadline. Response quality now predicts response quality later.
58. Call the references — three per finalist, at your size, in your industry.
59. Ask referees what took longer than expected, not what went well. The useful information is in that answer.
60. Request a second session on anything unresolved. A vendor unwilling to return for a serious buyer is telling you something.
61. Get the complete written quote before you rank anyone commercially.
Frequently Asked Questions
How long should an ERP demo be?
At least half a day per finalist, and often two sessions — one covering core processes, one covering reporting, integration and technical questions. A ninety-minute session shows you a highlights reel, not a system.
Should end users attend the demo?
Yes, and they should score it. Management evaluates strategic fit; the people who will use the system daily evaluate whether their work gets faster or slower. Those assessments frequently differ, and the difference is important information.
How many vendors should we demo?
Three finalists, after screening a longer list on must-have requirements. Fewer gives you no comparison; more exhausts your panel and produces shallower scoring across every candidate.
Should we send scenarios in advance?
Always. Advance scenarios give every vendor the same opportunity and make the sessions genuinely comparable. Vendors who resist demonstrating your scenarios and insist on their own script are telling you something worth hearing.
What is the single most revealing demo question?
Asking to see something go wrong — a mis-picked order, a posting to the wrong period, a partial return with a credit and restock. Vendors rehearse the happy path exhaustively. How gracefully the system handles correction and reversal tells you far more about daily life with it.
How do we stop being impressed by presentation quality?
Score against written criteria during the session, use identical scenarios for every vendor, and mark must-haves as pass or fail independently of the total. Demo skill correlates with the quality of the sales engineer, not with the quality of the software.
Should we ask about price during the demo?
Ask for the complete written quote afterwards rather than negotiating live. Collect all quotes before comparing any of them, so the first figure you hear does not anchor your judgement of the rest.
What if a vendor refuses to answer something?
Record it and follow up in writing with a deadline. Some questions genuinely need checking. A pattern of deflection, particularly on references or exclusions, is data about how the relationship will run after the contract is signed.
Conclusion
The purpose of a demo is not to be shown a system. It is to test specific claims against your own scenarios, in front of the people who will live with the result. Everything in this list serves that purpose.
Send your scenarios in advance, bring your awkward cases, put real users in the room, ask to see things fail rather than succeed, insist on named references at your size, and get a complete three-year quote with exclusions listed. Do that and the decision will be based on evidence rather than on which vendor had the better presenter.
Leave a Reply