How to run a scripted ERP demo on your own data

Every system on your shortlist can run order to cash. The only information in a demo is how hard it was to make it run yours. The script tests the configurator and the partner, not the product.

Guide  ·  updated 2026-10-17

Search the query and open the first ten results. Nearly all of them are lists of questions to ask, thirty or fifty of them, grouped by module. Write your own script, use your own data, test the exceptions, score it on a matrix: consensus advice now, so none of it is a position. What none of them contains is the script. A list of questions is answered in the room, out loud, by the person selling. A script is three transactions somebody has to make the software do while you watch. Below is the script, the rule used to choose the three, and the grade sheet that replaces the weighted matrix.

The arithmetic that explains the number three

Start with the scarce thing. Ask each finalist for ninety minutes of live screen with your own material loaded on it. Not ninety minutes of meeting: a mouse moving while you watch. Ninety is about the most a sales engineer will agree to and still prepare for properly, so treat it as a figure to negotiate for rather than a measured average. The whole shape of the agenda follows from whatever number you settle on, and the agenda is the part worth sending in advance.

Send the agenda with the minute marks and hold them to it. Eight scenarios in ninety minutes is a guided tour with your logo on the slides. Three leaves time to watch how the work got done. If you negotiate more than ninety minutes, spend it on a second cold-navigation task rather than a fourth scenario: the marginal scenario tells you less than the marginal unrehearsed record.

Pick transactions that cross a boundary

Here is the selection rule the published checklists leave out: choose transactions that cross a boundary. A boundary is where the system must reconcile two things that disagree. An open period against a closed one. A purchase order against what arrived. One unit of measure, or one entity, against another.

Boundaries are cheap to avoid in a demo tenant and expensive to get wrong in production. A sales dataset is built so nothing crosses one. A happy-path scenario asks that tenant a question it was built to answer. A boundary asks whether the answer exists, and who builds it.

The three transactions

One: the period boundary

Your worst real credit note, dated into a month that is already closed. It must land on the original cost centre and the original revenue account rather than a catch-all code, and the original invoice must stay traceable from it. Better still if that invoice is part-paid. Where it lands is also the first live test of whether your chart of accounts survived the mapping. Watch for the system that posts to the current period and keeps the real date in a memo field. At year end that difference is an audit question.

Two: the match boundary

A purchase order for 100 units at one price. A delivery of 60 at another price. An invoice for 100. The short shipment then arrives after the invoice is posted, which is ordinary in goods-in and will not be in the vendor’s own script. Quantity and price disagree, and the two are resolved in different places by different people.

Three: the unit boundary

Buy by the pallet, hold stock by the case, sell by the each, with arithmetic that leaves a remainder: a fraction of a case that has to go somewhere, and a cost with it. Hold no stock and this becomes a cross-entity recharge with a markup, where the margin must eliminate.

Each of the three can be handed over tomorrow with the real document attached. None needs a specification.

The data pack, specified

Advice to send sample data in advance treats it as free. It is not, and the shape of the pack decides whether anything useful happens. One CSV per master file, about fifty real rows, plus the documents as PDFs.

Send it ten business days ahead, and ask for the loaded tenant to be confirmed by day seven. A tenant load is several hours of real work for a sales engineer who has other finalists this month, and short notice is the usual reason a demo booked on your own data arrives as the standard one with your logo on it. That is an observation from practice rather than a measured rate, and the test is cheap: ask on day seven whether the data is in. Send the pack under the vendor’s non-disclosure agreement rather than yours, because their lawyer’s own template is the one their legal team signs without a week of redlines.

One written instruction goes with it. Do not clean it. A vendor who returns cleaned data has answered your migration question early, because somebody decided things about your master records without asking. The migration checklist says why those calls are yours.

Three columns, not a number

Weighted scorecards treat four kinds of evidence as one input. A rating out of five cannot distinguish ran live on your data from ran on their clean data, nor either of those from described out loud and shown on a roadmap slide. What a demo actually measures is whether the consultant in the room can make the software do this, and a scorecard records that as what the product does natively, which is the one conclusion a four out of five cannot support. So grade each step in three columns instead, and carry the columns rather than a total.

Promised scores zero. A Promised item you are willing to live with goes on the gap list and gets attached to the statement of work, or it has not been accepted, it has been forgotten, and it comes back in testing as a change order. Configured is an invoice either way, and it is cheaper to price it in the room than to meet it in process design.

Who drives, and cold navigation

For the last five minutes of each transaction, the person who does that job today takes the mouse. Not IT, not the sponsor, not the consultant. Count the clicks, then ask: could you do that on the Friday of month-end without calling anyone. A keyboard not handed over, or a login that cannot post, is itself an answer.

Then cold navigation. Name a record from your pack they have not shown: open the invoice for customer X, line 3, and say which accounts it posted to. Three things to watch, in order of what they reveal.

• Global search, or a memorised path. A remembered menu route means a rehearsed screen. A search box means the product as your staff will use it.
• Leaving the screen to set something up first. Each departure is configuration missing from the standard build. Mark it Configured and ask who sets it.
• A report, or a spreadsheet export. The spreadsheet is the finding: if the number comes from Excel here, your month-end lives outside the ERP.

The four stock answers

Ask these at the end of each transaction, worded so a yes is expensive to give.

1. Which of those steps was a setting, and who sets it: you, us, or support?
2. Show me the audit-trail entry that transaction just wrote.
3. Which release is that in, and is it on by default in my region’s build?
4. Who on your side will be in the room during our cutover, and were they in this one?

One of four answers comes back. Each has a translation.

Four ways to see it run

A scripted demo is one of four routes, and it is not always the right one. Compare them before booking. The costs and lead times are what to ask for and what partners generally agree to, not measured averages.

§

What can wait for the pilot, and what cannot

One rule sorts it. Anything touching money that has already moved must be proved before signature: reversals into closed periods, three-way matching, tax determination, intercompany, costing, and the audit trail behind all of them. Screen layout, report formatting, dashboards and permissions can wait for the conference room pilot, because each of those configures a decision that has already been taken rather than taking it. A pilot that inherits the first list instead is one of the four mechanisms in why implementations fail.

Everybody agrees the pilot follows selection. Nobody says which questions it is allowed to inherit, which is how an unproved boundary becomes a problem you own. The ones it may not inherit are exactly the ones whose answer would have changed which vendor you signed, and after signature that answer costs a change order rather than a phone call to the runner-up.

What you leave with

Three artefacts, or the session did not happen.

• The screen recording. Ask at booking, not at the end. A demo you cannot replay is a memory, and memories lose comparisons two weeks later.
• The written config notes for every Configured step, one line each. Your implementation estimate gets built from this list.
• The signed gap list. Every Promised item, named, with an owner, attached to the statement of work.

Note what is absent: a fit percentage. A high per cent fit quoted against a few hundred binary requirements is unfalsifiable in both directions, because nobody can state which requirements the denominator held or how each yes was evidenced. Ask the two questions anyway, of any fit figure you are handed, and watch it dissolve. Three graded transactions and a signed gap list say less and mean more.