A demo is built to go well

A vendor demo is a rehearsed performance with clean data and a presenter who has run it fifty times. Every account has a phone number, every opportunity closes, and the one person in the room who could break it is the person driving. None of that is dishonest. It is what a demo is for, and if the vendor sets the agenda you get a very good demo and almost no evidence.

I have sat on both sides. On the consulting side I have helped build the demo org, and I know which records we hid. On the buying side, evaluating Dynamics 365 Sales against Sales Cloud and Oracle CX Sales, I have watched a two-hour session end with everyone impressed and nobody able to say whether the product would survive our territory model. The difference is who wrote the script.

So write it. Send the scenarios early, bring your own records, ask to see something break, and write down what you saw the same day. The method works for a service desk or an ERP evaluation too, which is why it sits with our other consulting pieces.

Send the script before the vendor sends the deck

Three weeks before the session, send the vendor a written script. Not a requirements matrix with four hundred rows. Six to ten scenarios, each a short paragraph describing a real day in your business with the real names of the roles involved. A rep in the German entity converts a lead that already exists as a contact on a US account. A partner manager needs pipeline for accounts she does not own. A finance analyst pulls closed-won revenue after three deals were reassigned between regions.

The vendor will push back, politely. They will ask to reorder the scenarios, substitute one of theirs, or cover one on slides because the demo environment is not set up for it. Some of that is reasonable. But when a scenario moves to slides, write it down, because the product either cannot do it out of the box or the vendor is not confident it can. Both are things you wanted to know.

Ask in the same email who will be driving. A presales engineer who built the org shows you the product configured by an expert. An account executive who has never opened the admin settings shows you the product configured by nobody. You want the first person driving and the second answering the commercial questions, and it is fair to say so.

These are the scenarios I put in almost every script. Swap the objects for yours and keep the shape.

  • A lead conversion where the contact already exists on a different account, to see how duplicates are caught and merged.
  • A record with a missing required field arriving through an integration rather than a screen.
  • A user who needs to see records they do not own, under your real territory or legal entity rules.
  • A change that has to be undone. A reassigned opportunity, a deleted product line, a price book update that was wrong.
  • A report your finance team actually runs, produced from the demo data, with the number checked against a calculator.
  • One scenario the vendor chooses, so you also see the product at its best.

Bring your own records, duplicates included

The demo org has clean data because someone cleaned it. Your production CRM has three versions of the same customer, a legal entity structure that changed after an acquisition, and a custom field called Region2 that half the sales team ignore. Bring a sample. Two hundred accounts, five hundred contacts, a few hundred opportunities, anonymised, with the mess left in.

Ask the vendor to load it before the session, then ask to see the load report. I care less about whether the import succeeded than about what happened to the twelve accounts that share a name and a postcode. Did it flag them, merge them, or create twelve more? When the duplicate rule fires in Sales Cloud or the detection job runs in Dynamics 365, what does the rep see, and can they override it? If the sample was cleaned first so the demo would run, you have learned which feature the vendor did not want you to watch.

The legal entity question matters more than people expect. If you sell from four entities in three currencies and report to one parent, you need to see an opportunity created under the wrong entity and moved, and what happens to the exchange rate and the forecast when it moves. A demo that only creates records in one entity has not touched the part of your model that will make the implementation slip. The same questions come up when a project decides which identifiers survive a system change, and the demo is the cheaper place to ask them.

Ask to see something fail

Every product handles the happy path. The evaluation is about the other paths, and nobody volunteers those. So ask directly. Show me an integration message being rejected. Show me a user opening a record they are not allowed to see. Show me an import that half succeeded, and how an admin finds out which half.

Watch the screen and, more usefully, the room. A confident presales engineer will find the rejected message in the integration log, show you the payload, and explain who gets notified. A less confident one will say the middleware handles that, or that it depends on configuration. The second answer is often true, but it means the failure path is yours to design, and you should cost it that way.

The permissions denial is the one I never skip. In one evaluation I asked what a rep in a shared services team saw when they searched for an account owned by another region. One product showed a blank list with no explanation. Another showed the account name and a button to request access. The third showed everything, because the demo org had one profile and nobody had built the sharing model. Three products, three very different amounts of work waiting after signature. A demo is also the first place to test whether a product can hold the rules a shared customer record needs.

Rollback is the last one. Ask for a change to be made and then undone. Fifty opportunities reassigned to a new owner, then reversed. A price book update applied and withdrawn. You are looking for an audit trail a business user can read, whether the reversal is a feature or a support ticket, and how long it took. How a product surfaces failure tells you more about the next five years than any feature list.

Write it down before you leave the room

Notes from a demo decay fast. By the next morning three people remember the same screen three different ways, and by the time the second vendor presents, the first has blurred. So I keep a single page per vendor, fill it in during the session, and tell the vendor that is what I am doing.

The page has four columns. What we asked for. What we saw, with the scenario number. Who drove it. And whether the answer was shipped, configured for this demo, on the roadmap, or on slides. That last column is the one that matters at contract time. Roadmap answers are pleasant in a demo and worthless in a statement of work, and you will not remember which was which unless you wrote it down as it was said.

Compare notes across vendors the same day if you can, and within the week at the latest. Book the debrief before the demos, and invite the admin who will run the product alongside the sponsor who will sign for it. The admin will remember the sharing model. The sponsor will remember the dashboard. Only one of them is going to be on call. If the demo bundles features you expected to buy separately, the total-cost questions inside a simplified edition belong in the same debrief, along with a proper read of the licensing terms before a quote reaches finance.

The demo is the cheapest test you will ever run

A vendor will occasionally decline. The script is too custom, the demo org cannot take your data, failure paths are covered in the proof of concept. Sometimes that is fair. But a proof of concept costs weeks of your own people's time and often a paid engagement. A demo costs an afternoon. If a vendor cannot show you a duplicate merge and a permissions denial in an afternoon, ask what the proof of concept is going to find.

What I say in that meeting is short, and I say it kindly. We are going to buy one of these products and live with it for years. We would rather see it stumble in your org than in ours. Show us the scenarios in the order we sent them, tell us plainly which ones are roadmap, and we will remember you as the vendor who did.

Send the script this week. Pick the six scenarios your sales operations lead complains about most, write each as a paragraph, attach the anonymised export, and ask who is driving in the same email. The demo that comes back will be shorter and rougher than the one you would otherwise get, and it will be the only one of the three you can use.