A software demo is a well-made thing. Someone who knows the product very well walks you through it, using data built to look clean, along a path that has been shown many times before. Screens load quickly. Reports appear with a click. Everyone in the room leaves impressed.
That is the problem. A demo is designed to answer one question: does this software work? Almost always, it does. The question that decides whether your project succeeds is a different one: does this software work for your business, with your people, your exceptions and your data? A demo was never built to answer that.
This article covers what a demo leaves out, why it leaves it out, and how to find out whether a system really fits before you commit to it. We use business systems like ERP as the main example, but the same gaps apply to most software a business buys to run its operations.
What "business fit" actually means
Business fit is how well a system supports the way your business really works, without forcing your team into workarounds or forcing you into custom development you did not plan for.
It is not the same as features. Two systems can both "have" inventory, invoicing and purchasing, and one can fit your business far better than the other. Fit is about the details: how a partial shipment is handled, who can approve what, how pricing exceptions work, what happens at month-end, and how much effort it takes your team to do the work they do every day.
A demo shows features. Fit lives in the details a demo skips.
Why demos leave out the parts that matter
This is not about dishonesty. Most demos are given by people who believe in their product, and what they show is real. The gaps come from how demos are built:
- They are built around the product, not your business. If you have not told the vendor what matters to you, the demo fills the time with what the product does best.
- They run on prepared data. A few customers, a few products, no history, no mistakes.
- They follow the happy path. The order that ships in full, on time, at list price, to a customer who pays.
- They are run by an expert. The person clicking has done it hundreds of times. Your team will do it for the first time.
- They are short. An hour or two cannot cover a month-end close, a returns process and a year of reporting.
So the demo answers "can it?" and leaves "will it, here?" for later. Later is usually after the contract is signed.
Seven things a demo will not tell you
1. How it handles your exceptions
Every business has a normal way of doing things and a long list of exceptions: the customer with special pricing, the order that ships in three parts, the product that gets modified before it goes out, the supplier who sends the wrong quantity. Those exceptions are where your team spends much of its time, and they are exactly what a standard demo leaves out.
If the system handles your exceptions well, great. If it does not, your team will handle them outside the system, in spreadsheets and email, and the new system will quietly become one more place to update.
2. How it behaves at your volume
A demo database has a few dozen records. Yours will have years of history, thousands of products or customers, and busy periods where everyone is in the system at once. Search, reporting and screens that feel instant with demo data can feel very different with real data. Ask what the system looks like for a business your size, and ask to speak to one.
3. What it takes for each person to do their job
A demo shows a task done once by an expert. It does not show what a customer service rep, a warehouse picker or a bookkeeper goes through fifty times a day. How many screens? How many clicks? What do they need to remember? A step that takes ten extra seconds is invisible in a demo and adds up to hours across a team.
The best way to see this is to have the people who do the work watch the demo of their own part, or better, try it themselves.
4. How roles, approvals and access will really work
Who can change a price? Who approves a purchase over a certain amount? Who can see payroll or margin figures? Demos are usually run with full access, so none of these questions come up. In real use, getting permissions and approvals right is often a large part of setup, and some systems are far more flexible than others.
5. What month-end and year-end look like
Demos show transactions: a quote, an order, an invoice. They rarely show what finance does at the end of the month to close the books, reconcile accounts and produce the reports leadership relies on. If your finance team is not in the room when the system is evaluated, this gap often surfaces after go-live, when it is most expensive to fix.
6. How it connects to everything else you use
Your business already runs on other tools: an online store, a shipping service, a payroll provider, a bank, a reporting tool, a customer's ordering portal. A demo might show a logo on a slide that says "integrates with". It will not show what that connection actually moves, how often, who looks after it, and what happens when it fails. Each connection is its own small project, and they are a common source of change orders.
7. How much of the work lands on you
The demo shows the finished result. It does not show the work it takes to get there: cleaning and moving your data, deciding how each process should run, setting up every user, testing, writing procedures and training your team. Much of that work belongs to your business, not the vendor, and most proposals only cover the vendor's part. A system that fits well on paper can still fail if nobody planned for the effort on your side.
How to find out whether a system fits
None of this means demos are useless. It means a demo is one piece of evidence, not the decision. Here is how to get the rest.
Write down what your business needs first
Before any demo, write down how your business works today and what it needs the new system to do. Separate the needs you cannot run without from the ones that would be nice to have. Without that list, you have nothing to measure the demos against, and you end up comparing three sales presentations instead of three systems.
Give every vendor the same real scenarios
Turn your most important needs into five to eight real situations from your business, including the awkward ones, and ask every vendor to walk through them in the same order. This is often called a scripted demo. It changes the meeting from a presentation into a test, and it makes the systems comparable side by side.
A good scenario is specific: "A customer orders 200 units across four sizes, 150 ship now and 50 are back-ordered, and the customer gets their contract price, not list price. Show us the order, the shipment, the back-order and the invoice."
Ask what was configured to show you that
For anything that matters, ask whether what you saw works the moment the system is installed, needs setup, needs custom work, or was built just for the demo. They all look the same on screen, but they have very different costs. This is one of the questions vendors hope you do not ask, and one of the most useful.
Put the right people in the room
Bring the people who do the work, not only the people who sign off. A warehouse lead, a customer service rep and someone from finance will notice things a leadership team will not. Give each of them a simple scoring sheet built from your list of needs, so feedback is about fit, not about whose screens looked nicest.
Get hands-on time for the processes that matter most
For your two or three most important processes, ask for a trial environment or a working session where your own people try the system with a sample of your real data. It takes more time than a demo. It also shows things no demo will.
Talk to businesses like yours
Ask for references of a similar size and industry that went live recently, and ask them about the gaps: what they had to work around, what took longer than expected, and what they would do differently. Their answers will tell you more about fit than any feature list.
Signs a demo is selling rather than showing fit
Watch for these during and after a demo:
- The vendor avoids your scenarios and returns to their standard script.
- Questions about exceptions are answered with "the system supports that" and no example.
- Anything difficult is "something we would configure during the project".
- Nobody can tell you what was built specially for the demo.
- The demo team will not be the team that implements your system, and you have not met the people who will.
- You leave impressed but cannot say how the system handles your three most common problems.
None of these means the system is wrong for you. Each one means you do not yet know whether it is right.
The decision is about fit, not features
Most business systems on a shortlist can do what a business needs, in principle. The difference between a project that works and one that struggles is rarely missing features. It is a poor fit that nobody tested: exceptions handled outside the system, roles that do not match how people work, connections nobody scoped, and preparation nobody planned for.
A demo is the start of that test, not the end of it. The businesses that choose well are the ones that know what they need before the first demo and use every meeting after it to check.
If you are not sure your business is ready to evaluate systems yet, start with the readiness checklist or read how to know if your business is ready for a new ERP.
Where we fit
We work on the buyer's side. In ERP selection we write down what your business needs, turn it into real scenarios, run the same test with every vendor and score the results with your team. We sell no software and take no referral fees, so the only thing we are measuring is fit.
Common questions
What is a scripted demo?
A scripted demo is one where you give the vendor your own scenarios in advance and they walk through them in the order you set, rather than showing their standard presentation. It makes demos from different vendors comparable and puts the focus on your business instead of the product's highlights.
How many vendors should we see demos from?
Usually two or three serious options after an initial shortlist. More than that and the details blur together; fewer and you have little to compare against. The scripted scenarios matter more than the number of vendors.
How long should a demo be?
Long enough to cover your scenarios properly. For a business system that runs several departments, that often means more than one session, split by area, so the right people from your team can attend each part.
Can we trust a demo at all?
Yes, for what it is designed to show: that the software works and roughly how it looks. Just do not let it answer the question it was never built for. Whether the system fits your business is something you have to test with your own scenarios, your own people and your own data.
Facing this now?
ERP Selection
Help choosing the right system, from an advisor with nothing to sell you.