Scale
A list of thirty records is instant in any product ever written. The same screen with two hundred thousand records is where search slows down, filters time out and the export fails halfway. A demo's sample data is small on purpose, so the screens you see are the fastest those screens will ever be.
Get the evidence: ask for a demo environment loaded at your volume, or ask a reference customer of your size one question: which screens are slow? Everyone who uses a product daily knows the answer immediately.
Permissions
You are almost always the administrator in a demo, which means you never meet a locked door. Real use is the opposite. Most of your people will have narrow access, and the questions that matter are about them: can a warehouse user see prices, can a contractor see other contractors' work, can a customer see only their own orders?
Get the evidence: in a sandbox, add a second user with the least access the product allows and sign in as them in a private browser window. What that user can still see is the real answer, whatever the permissions page claims.
Integrations
A demo is an island. The connection to your accounting system, your carrier, your identity provider or your warehouse scanners is not there, and the screen that says "connected" in a sales demo is connected to a test account the vendor controls. Integrations are where projects overrun, because they depend on a second company's system behaving.
Get the evidence: ask who builds and maintains the integration, the vendor or a third party; ask to see the documentation for it rather than a slide; and ask what happens to records when the other system is down. An integration that matters belongs in a proof of concept.
Getting your data in
Sample data is clean. Yours has duplicate customers, part numbers with trailing spaces, dates in three formats and a column somebody repurposed in 2019. The import screen in a demo is shown with a file built to succeed.
Get the evidence: take a few hundred rows of your real export, problems included, and try to import them. Note what was rejected, what was silently changed and whether the error messages told you which row and why.
Getting your data out
Nobody demos the exit. But the day you leave a product, or the day an auditor asks for five years of records, you need everything out in a form another system can read. Some products export a summary of each record and keep the history, the attachments and the audit trail.
Get the evidence: in the sandbox, export everything you can and open the files. Look for the history and the attachments, not only the current values. Then ask what a customer who cancels receives, and in what format.
The failure paths
Demos follow the path where everything works. The software you will actually use spends part of every day on the other paths: the duplicate entry, the wrong unit, the record somebody else edited at the same moment, the step done out of order. How a product behaves when you are wrong tells you more than how it behaves when you are right.
Get the evidence: break things on purpose. The demo checklist has a section of deliberate mistakes to make.
Setup and administration
A demo arrives configured. Somebody chose the fields, the statuses, the workflow steps and the report layouts before you opened it. Your version starts empty, and the weeks between signing and the first useful day are spent in settings screens the demo never visited.
Get the evidence: ask to see the product in its unconfigured state, and ask how long a customer like you typically took to go live and who did the work. If the answer is "our services team", ask what that costs.
Support
During an evaluation you have the attention of people whose job is to win you. After signing you have a support queue. The two are not the same people, and a demo tells you nothing about the second group.
Get the evidence: send a real question through the public support channel while you are evaluating, without mentioning the sale, and time the reply. Read the last few months of the public status page and release notes if there are any.
The whole cost
A demo has no price on it. The number you are quoted later is for the license; the cost includes migration, integration work, training, the modules that turned out to be extra and the time your own people spend on all of it.
Get the evidence: ask for a written quote that lists what is not included. Vendors answer this question precisely when it is asked precisely.
Turning the list into questions
None of this means a demo is worthless. It means a demo answers "does it do the thing" and leaves "will it work for us" open. Write the nine headings above down the side of your scorecard and mark each one as seen, told or unknown. The unknowns are your agenda for the sales call.
Ask what their own demo does not show. A vendor who can list the limits of their demo has thought about your evaluation; one who says the demo covers everything has not. The worked example on this site answers that question for the demo we run ourselves.