A Demo Is Theatre Unless You Control the Script

The demo you were shown last week was rehearsed. Not deceitfully — rehearsed the way a stage play is rehearsed, because a salesperson who improvises in front of a buying committee is a salesperson who loses deals. Somebody built that dataset. Somebody chose that order of clicks precisely because it avoids the three screens where the product is awkward. The customer record they open has every field populated, the stock is in the right warehouse, and the approval hierarchy has exactly two levels because three would have needed a scroll.

None of that is a scandal. It is what a demo is. The problem is that buying committees treat it as evidence, and it is not evidence of anything except that the vendor prepared.

A demo becomes useful the moment you write the script. Everything below is about how to write one, and what specific asks force a product to reveal itself.

The four asks that do most of the work

You can spend a whole day on a demo and learn less than you would from four requests, sent in advance, in writing.

Bring my data. Not a sample of it later. A small extract of the real thing, in the demo, on screen.

Show me the failure path. Not the happy path where the delivery matches the order. The one where it does not.

Show me the upgrade. What happens to everything you have just shown me when the product releases its next version.

Show me who does this after go-live. The person in the room today is very likely not the person on your project, and it is better to find that out in the room.

Everything else in this article is detail underneath those four.

Ask one: bring my data

Send every vendor the same extract, two weeks ahead, and require them to use it. Keep it small enough to be honest work and large enough to hurt.

A useful extract contains twenty or thirty customers with your actual naming mess intact — the same company under three spellings, the trade licence name that differs from the name everyone uses, the one with Arabic characters in it. Fifty items, including the ones with a unit of measure nobody can explain. One bill of materials or one bill of quantities, whichever your business runs on. A partially delivered purchase order. A supplier invoice in a foreign currency. A credit note that relates to a prior period. And the one transaction your own team argues about, whatever it is.

That last item is the most valuable line in the extract. Every company has a transaction that produces a disagreement between two departments. Watching a vendor handle it tells you more than an hour of slides.

Two things happen when you insist on real data. The first is that some vendors decline, or agree and then quietly present their own dataset anyway. That is a result, and you should record it as one. The second is that the demo slows down, visibly, in the places where the product needs help. Those places are exactly the ones you will live in.

Watch for the specific tells. A duplicate customer that the system happily creates twice, with no warning. A name that renders correctly in one screen and as question marks in a report. An item code with a space in it that breaks a search. A foreign-currency invoice where the exchange difference goes somewhere nobody can name. None of these appear in a curated dataset because the curator removed them.

Ask two: show me the failure path

Rehearsed demos show the transaction succeeding. Your business is not made of transactions succeeding. It is made of the eleven per cent that go sideways, and the cost of an ERP is very largely the cost of handling those.

So script the exceptions and refuse to accept a verbal answer to any of them.

Ask them to show	What you are really testing
A delivery arrives short. Receive part of it, keep the order open, then receive the rest next month	Whether partial fulfilment is native or a workaround with a manual balance somewhere
A customer returns goods that were invoiced in a closed period	Whether the system forces a clean credit note, or whether someone reopens a period
A purchase order needs a second approval because it crossed a threshold after being edited	Whether approval rules re-evaluate on change, or only on submission
A user tries to post to a period that is closed	What the message says, and whether a normal person could understand it
An invoice is posted with the wrong customer and discovered a week later	Whether correction is a documented path or a database conversation
Two people edit the same record at the same time	Whether anybody loses work silently
A payment is received for less than the invoice, with the difference being a bank charge	Whether settlement handles it or somebody journals it every month

The last column is the point. You are not testing whether the product can do the thing. Nearly all of them can, eventually. You are testing what it costs a normal user to do it on a Tuesday, and whether the workaround leaves a trace that an auditor can follow.

There is also a behavioural test buried in this section, and it is the most predictive minute of the whole day. Something will go wrong during the demo. A screen will not load, a record will not save, a figure will be visibly incorrect. Watch what the vendor does. The ones who say "that is not right, let me find out why" and then actually find out are showing you what your project's issue log will feel like. The ones who move the mouse quickly to the next screen are showing you that too.

Ask three: show me the upgrade

This is the question almost nobody asks, and it decides what year three costs.

Every vendor will tell you the product is upgraded regularly and that upgrades are included. Both statements are usually true and neither answers the question, which is: what happens to the specific things you are about to build for us?

Make it concrete.

Ask them to show you a customisation they built for another client and explain, on screen, what happened to it at the last major version. Ask which parts of what they have just demonstrated are standard product, which are configuration, and which are code — and ask for that split in writing before contract, per requirement, because the answer changes when it has to be written down. Ask what their oldest client is running, and why that client has not moved. Ask who pays for the regression testing of your bespoke pieces when the platform version changes.

The written split matters more than it sounds. Configuration is a decision recorded in the database; it survives an upgrade with no attention. A customisation is code that assumed the shape of the product at a moment in time, and every version bump is a small negotiation with that assumption. A system that is largely configured has an upgrade path. A system that is largely customised has an upgrade project, repeated indefinitely, and the honest way to see the difference early is to make the vendor classify each of your requirements before you sign rather than after. That classification is the same judgement discussed in when to configure, when to customise and when to build, and a demo is the cheapest place in the whole process to force it into the open.

Ask one more thing while you are here: whether the version they are demonstrating is the version you would be implemented on. Sales environments are often ahead of what partners deploy.

Ask four: show me who does this after go-live

The person driving the demo is frequently a pre-sales consultant whose job ends at signature. This is not hidden; it is simply never asked about, and the assumption fills the gap.

Ask directly, in the room: will you be on this project, and for how many days? Then ask for named individuals with CVs for the delivery team, and a key-personnel clause in the contract that requires your consent before they are replaced. A vendor who will commit names is making a real promise. A vendor who offers a logo slide and a resourcing model is telling you that the team is whoever is free in month two.

Then follow the same thread past go-live. Support is a different organisation from delivery in most partners, and the handover between them is where knowledge goes to die. Ask who answers the phone when the invoice run fails on the twenty-eighth. Ask what the response commitment is, in hours, during your month-end rather than in general. Ask whether the person who configured your approval matrix will be reachable in month fourteen, and what it costs to reach them.

There is a related question that gets an unusually honest answer because it sounds administrative: how many live clients does the consultant assigned to us currently support? If the number is large, your escalations are queuing behind somebody else's.

The rules that govern the room

Four rules do most of the work of keeping a demo from turning back into a performance.

Same script, same order, same audience, same scoring sheet, every vendor. Otherwise you are comparing presentations rather than products, and the vendor who went last has an advantage that has nothing to do with software.

Say "show me", never "can it". "Can it handle retention?" gets a yes from everyone, correctly, because everything can handle everything with enough effort. "Show me a retention amount held on this certificate, released in a later one, and appearing on the customer statement" gets a demonstration or a confession.

Count clicks on your highest-volume transaction. Have someone from your team time it with a phone. Multiply by your monthly volume. A difference of four clicks on a transaction you do a thousand times a month is a headcount conversation, and it is invisible in a feature comparison.

Let the people who do the work sit in and speak. The storekeeper will spot in ten seconds what the steering committee misses all afternoon. This has a second benefit that is worth as much as the first: the people who will have to use the system saw it being chosen, which changes how they behave in month seven. It is the cheapest resistance-management available.

Scoring, so that the decision survives the meeting afterwards

A demo without a scoring sheet becomes a memory contest, and memory contests are won by whoever presented most confidently. Score in the room, individually, before anyone discusses.

What you score	How	What counts as evidence
Each scripted scenario	Completed, completed with a workaround, or not completed	What was on the screen, not what was said about it
Clicks and elapsed time on your highest-volume transaction	Counted and timed by your own person	A number, written down during the demo
Each exception scenario	Standard, configuration, customisation, or a process change demanded of you	Which of the four, stated plainly by the vendor
Reporting	The vendor builds a report you name, in the room, from the data you supplied	Not a pre-built sample, and not "we can do that"
Behaviour when something broke	Diagnosed, deferred honestly, or skipped past	Your own observation, recorded before you leave
The team	Named individuals, availability, and a willingness to put both in the contract	CVs and a clause

Keep the sheets. Six months later, during a difficult phase, somebody will say the product was never going to work. The sheets are how you know whether that is true or whether the design decisions were the problem.

What a demo cannot tell you, however well you script it

It is worth being clear about the limits, because a well-run demo day produces a confidence that outruns its evidence.

A demo cannot tell you how the system performs at your real volume. Thirty records behave differently from three hundred thousand. It cannot tell you whether the configuration survives your month-end, because a month-end takes a month. It cannot tell you whether support answers. It cannot tell you what the second year costs. And it cannot tell you whether the numbers it produces will be trusted, which turns out to be a question about data ownership rather than software, and the reason a dashboard can be technically correct and still lie.

Those answers come from three other places. Reference calls you arrange yourself, with no vendor on the line, including at least one reference the vendor did not choose. A small paid discovery before the main contract, which is the closest thing to a trial that exists in this market — and a partner who refuses to sell you one has told you something useful. And the contract itself, where acceptance criteria written as tests are worth more than any assurance given in a room.

Sector questions that end demos early

Generic scripts get generic results. If your business has a shape, script for the shape, and put those scenarios first while everyone is still fresh.

A contractor should be asking to see a measured quantity flow into a payment application, retention held and later released, an advance recovered proportionally, and a variation order that changes the contract value without breaking the original budget baseline. Those four make up most of the reason contracting businesses outgrow generic ERP.

A manufacturer should be asking for a work order that consumes more material than the bill of materials specified, a subcontracted operation, a batch that fails inspection after part of it has been shipped, and a costing that reconciles to the ledger rather than sitting alongside it.

Every UAE business should be asking to see a VAT return reconciled line by line to the ledger for a period, an invoice that is legally acceptable in Arabic, and the e-invoicing seam to an accredited service provider. Local requirements disqualify candidates for reasons nobody can argue with, which makes them the most efficient part of any script. If Odoo is on your shortlist, it is worth reading where the product genuinely fits and where it does not before you write those scenarios, so that you test the seams rather than the strengths.

Before you book anything

The order matters. A demo scripted from requirements you wrote by watching your own work is a test. A demo scripted from a vendor's feature list is a sales meeting with homework. If you have not yet done the observation stage, do that first; the vendor-neutral method for choosing an ERP in the UAE covers how to write requirements that a demo can actually falsify.

And when the demos are done and the shortlist is two, the remaining question is money — not the licence line, but the shape of where the implementation budget actually goes, which is where most of the difference between bidders turns out to live.

If you would rather have someone script and sit in on the demo day with you, that is part of how we run an ERP implementation from the selection stage onward.