Demo in the customer’s tenant, or tell the room plainly that what they are watching is a fiction. There is no third option that is honest, and the bill for pretending otherwise arrives around month three, on a programme with no money set aside to pay it.
Every demo tenant I have worked in holds about a dozen documents. All permissioned properly. None of them contradicting each other. Every one written in the last month by somebody who knew it would be retrieved. It is a lovely place, and nothing in it resembles anywhere that anybody works.
The customer has fifteen years of SharePoint, three intranets that nobody owns, and four versions of the expenses policy, two of which are called final. That is not a criticism of the customer. It is what happens to any organisation that has been busy.
A demo tenant differs in kind, not in size
The usual mistake is to treat the demo as a scale model, as though the customer’s tenant were the same thing with more in it. You could load four hundred thousand documents into a demo tenant and the answers would stay good, because the content would still agree with itself and still have owners. Volume is not what makes retrieval hard. Contradiction makes it hard, and so does genuine ambiguity about which copy counts.
Permissions differ in kind too. A demo tenant’s permission model was designed on a Tuesday afternoon by one person who understood all of it. A real tenant’s permissions are sediment. A site built for a merger that did not complete. A library shared with a broad link in 2019 to get a deadline met. A group whose membership has not been reviewed since the person who set it up left the organisation.
Then there is why the content exists. A demo document was written to be found. Real documents were written for other reasons: a deadline, an audit, a meeting, somebody covering themselves. Being findable two years later was nobody’s job and appeared in nobody’s objectives, and it shows.
The gap becomes a budget problem before it becomes a technical one
The business case gets written from the demo, because the demo is the only version of the product anyone senior has seen. One side of that case is easy to build. Licences have a list price, and the Microsoft 365 Copilot enterprise add-on is $30.00 per user per month paid yearly, so somebody multiplies it by a headcount and the number goes in the paper.
Nothing on the other side of the case has a unit price. Deciding which of the four policies is current. Retiring two of the three intranets. Giving twenty documents in each function a named owner and a review date. None of that has a SKU, a partner offer or a per-user figure to multiply, so it does not appear in the case at all, and a case that does not name a cost has quietly decided that cost is zero.
It comes back in month three as a discovery, and the timing is what does the damage. It lands after the licences have been paid for, which makes it read as an overrun rather than as scope. It has to be argued for by the same people who told the board this would be quick. In my experience that request gets half-funded, which is the worst available outcome, because half a content clean-up produces a tenant that is inconsistent in a new way.
The other thing the demo sets is the date. In a demo tenant there is value on the first day, so the plan promises value on the first day, and the first month gets judged against a promise made by a fiction. I have seen programmes declared disappointing at week six by executives who were, on the evidence in front of them, being perfectly reasonable.
Trust is what you spend in that gap
When the tool is right in the supplier’s tenant and wrong in the customer’s, users reach the obvious conclusion, which is that the tool is unreliable. The accurate conclusion is that their content is. Those two problems are fixed by different teams out of different budgets, and once the first belief has set you spend a year arguing against it, mostly with people who were in the room for the demo.
That belief is self-sealing, which is the part people underestimate. Users who have decided the tool cannot be trusted stop bringing you their bad answers. Bad answers are the raw material of the fix, because each one leads back to a document, a date and an owner. A quiet user base is not a settled one. It is a user base that has stopped telling you things.
It costs the supplier too. Every conversation after an oversold demo is one in which you are managing expectations downwards, and there is no way to do that which does not sound like an excuse. You spend the credibility you were given for the demo on explaining the demo. The gap you failed to describe in the first hour becomes the thing you are accused of hiding.
“We will show you this in your tenant” is the strongest sentence a supplier owns
In a competitive process, everybody’s slides say roughly the same thing, because it is the same product and everybody read the same documentation. The demos look alike for the same reason. There are only so many ways to summarise a mail thread in front of a procurement panel, and the panel has seen all of them by lunchtime.
The one differentiator available that is not rhetoric is an offer to run the customer’s own question, against the customer’s own content, live, in front of the people who own that content. Almost nobody offers it. The reason is obvious from the selling side: it hands control of the outcome to somebody else’s tenant, and no amount of preparation makes that safe. Which is exactly why it is worth so much. Anyone can promise a good result. Willingness to be wrong in front of a buyer is the only evidence that arrives before the contract does.
If you are buying, ask for it and treat the answer as information. A supplier who will only demo on their own kit is either not set up to work inside a real environment or has enough experience of what happens to prefer not to. Both are worth knowing while you can still walk away.
There is also a version of the offer that is not the offer. A supplier-written question, run against a supplier-chosen site, using an account somebody provisioned for the purpose that morning, is a rehearsal wearing a customer’s badge. The question has to come from them, the account has to be an ordinary one, and nobody should have run it before.
The honest demo will sometimes go badly, and that is the part to plan
Something like half the time it does. Plan the bad version, because the good version needs no planning.
- Do not explain it away. Reaching for “the model sometimes gets things wrong” is a reflex, and in a tenant like this one it is usually not even true. Say that you are going to find out where the answer came from, then do it.
- Trace it in the room. Open the document it used. Look at the date. Ask who owns it, and let the silence happen when nobody can say. Fifteen minutes of provenance teaches more than an hour of features, and the people watching will repeat it to colleagues afterwards, which no feature tour has ever achieved.
- Do not blame the prompt. Rewording the question until the answer improves ends the useful part of the session, and it teaches everyone present that failures are their own fault. They will believe you, and they will stop reporting them.
- Write it down as a finding, not an incident. “Four versions of the expenses policy, none marked current, owner unknown” is a line in a plan that you have just been given free of charge.
- Do not reach for the roadmap. A future release is not an answer to a present wrong answer, and offering one spends the credibility you earned by being straight thirty seconds earlier.
- Know when to stop demoing. If three questions in a row come back contradicting themselves, the demo is over and the meeting has changed. Say so out loud, and give the rest of the hour to the content.
One thing to settle before you start, because it catches people. An honest demo can surface content the person driving is entitled to open and was never meant to notice. Agree in advance whose account is used, agree that the owner of that account drives, and agree what happens if something sensitive appears: stop, note that it happened, do not screenshot it, and take it afterwards to whoever owns the site. Finding an oversharing problem in a demo is a good outcome. Finding one in front of eleven people from three departments with no agreed rule for what happens next is not.
What I ask for before I turn up
Three questions a week ahead, written by three people who do different jobs. One about a policy, one about a project, one about a customer or a case. I ask each person to tell me, before we run anything, which document they believe is the source of truth for their question. That answer is often the whole finding and it costs nothing to collect.
I use their account, on their machine, with them driving. I do not rehearse, and I say so at the start. I also say, before the first question, that some of these will be wrong and that the wrong ones are the reason we are all here. It lowers the temperature in advance, and it turns a bad result into material rather than an embarrassment.
For years I demoed in a clean tenant, because it works and because nothing awkward happens. I stopped after a session where somebody asked to run their question instead of mine, and the answer came back wrong in a way that took twenty minutes to unpick. It was the most useful twenty minutes of the day. Nobody in that room needed to be told afterwards why the content work was on the plan.
The best demo I have given returned a wrong answer. We spent the rest of the hour finding out whose document it came from, and what they bought three weeks later was the work they needed rather than the work I had arrived to sell.