The Demo Just Broke Live. Here's How to Keep the Room.

The environment times out. The dashboard loads empty. The one feature you built the entire story around throws a stack trace onto a shared screen in front of six people, two of whom already didn't want to take this meeting.

I have been in that room. I have also been the guy on the other side of the table watching a vendor melt. The gap between the reps who survive it and the reps who lose the deal in the next ninety seconds has almost nothing to do with the product and almost everything to do with what comes out of their mouth first.

So let's talk about what to do when a product demo fails, in the specific order you have to do it.

Everyone in the room already knows

Here is the thing new reps get wrong. When the demo breaks, they behave as though the break is a secret they might still be able to keep. They keep talking over the spinner. They say "it's just loading" in a voice that has gone up half an octave. They refresh, and refresh again, narrating each refresh as though the narration is a substitute for the feature.

The room already knows. They saw it. Buyers on a demo call are watching your screen with more attention than they will give anything else that day, because they came to find out where it breaks. That is the actual job of a buying committee — not to be impressed, but to find the failure mode before they sign for it. You just showed them one for free.

The question is no longer whether they noticed. The question is what kind of vendor they are dealing with when things go wrong. That is a much more valuable question for them, and it is a question you can actually win.

Name it in one sentence, then stop

The first sentence out of your mouth has to name the failure plainly, in language a non-technical buyer understands, and it has to be short.

"That's an error. The environment didn't return the account data."

That's it. Full stop. Don't editorialise. Don't apologise four times. Don't say "that's weird, it worked this morning" — every buyer has heard that sentence from every vendor and it lands as an excuse, not information. And whatever you do, do not begin troubleshooting out loud.

Narrating your troubleshooting is the single most damaging thing I see reps do on a broken demo. It sounds like this: "Okay so that's odd, let me just — I'll clear the cache — sometimes the sandbox does this if the token expired, hang on, I'm going to log out and back in, sorry, one second, Marcus do you know if the seed job ran last night?"

Every clause of that is a new piece of evidence for the prospect. Now they know the sandbox is flaky, that tokens expire unpredictably, that there is a seed job, that the seed job sometimes doesn't run, and that you don't have visibility into any of it. You have taken a single visible failure and turned it into a tour of your internal fragility. You did more damage in fifteen seconds of nervous talking than the error itself did.

Name it. Then either fix it silently or move.

The twenty-second rule

Here is the rule I hold myself to and the one I'd hold a rep to: you get twenty seconds of silent recovery attempts. One refresh, one re-auth, one "let me try the other account." You can do those while continuing to talk about something else, or in a short quiet beat. Twenty seconds.

At twenty seconds you switch paths. Not thirty. Not "one more try." Twenty.

The reason is not that the fix won't work at second forty. Sometimes it does. The reason is that the room's read on you changes somewhere in that window. Under twenty seconds, a break is a glitch and you are a person handling a glitch. Past it, the meeting has become about the glitch, and you are now a person who has lost control of their own meeting. Once that flips, getting the feature to load doesn't flip it back. You can fix the software and still lose the room.

So count. Genuinely count in your head. Reps who don't count always go long, because the fix always feels like it's one click away — that's what makes it a trap.

When the twenty seconds are up, say the transition out loud so it reads as a decision rather than a retreat:

"I'm not going to make you watch me debug our sandbox. Let me show you the same thing a different way, and I'll get you the live version this afternoon."

That sentence does three things. It says you respect their time. It says the failure is in your sandbox, not in the product logic you're about to describe. And it makes a commitment with a deadline, which you will keep, which becomes the first small proof that you do what you say.

You need a second path before you need it

All of the above only works if you have somewhere to go. The transition line is worthless if the next thing you say is "...actually, let me see what I've got."

So before any demo that matters, build the fallback. Three forms, in order of how much they cost you to make.

The screenshot deck nobody wants to build

Ten to fifteen still images of the exact flow you were going to demo, in order, with the data already populated. Not marketing screenshots. Your screenshots, from your last clean run, with realistic names and numbers in them. Keep it in a separate file, already open in another tab, before the call starts.

This is boring to build and it is the single highest-leverage asset a demo-carrying rep owns. It also has a second use: when you're up against a hard stop and you're at minute forty of a thirty-minute demo, you can jump to the last four screenshots and land the ending rather than getting cut off mid-flow.

The recorded run

A screen recording of the full happy path, no voiceover, so you can talk over it live. Two to four minutes. The value of the recording over the deck is motion — buyers evaluating a workflow tool want to see how many clicks something takes, and stills flatten that.

The risk of the recording is that it feels like a canned video, and canned video is exactly what a sceptical committee tunes out. So do not play it silently. Narrate it live, pause it, scrub backwards when someone asks a question. If you can pause and rewind on command, it reads as a demo you happen to be driving from a recording, not as a marketing asset.

The whiteboard version

The one most reps skip, and the one I'd take into a hostile room over either of the others. Can you draw the workflow — their workflow, with their terminology — on a shared whiteboard or a blank slide, and walk it end to end without the product on screen at all?

If you can, the broken demo becomes almost irrelevant, because what a serious buyer is actually buying is the model of how their work changes. The screen is evidence for the model. You can present the model without the evidence and then supply the evidence later. You cannot present evidence without a model and expect anyone to care.

This is the muscle worth building even for demos that never break. Almost every rep I have watched who can whiteboard their own product cold is also a rep who handles hard questions well, because both come from actually understanding the workflow rather than memorising a click path.

What you get in exchange for the failure

Here is the part that took me too long to learn: a demo that breaks and gets handled well can beat a demo that goes perfectly.

A perfect demo tells a buyer nothing about you. Every vendor's demo works in the vendor's own environment — that is the least surprising fact in enterprise software, and any buyer who has been through a few implementations discounts it heavily. The polish is exactly what they distrust. That's why the demo playbooks written for rooms that have already been burned, like the telecommunications demo script for a room that's been burned by AIOps, spend so much of their energy on showing the unglamorous parts rather than the reel.

A break gives you something a clean run can't: a live sample of how your company behaves when it disappoints them. That is the thing they most want to know and the thing they can never get from a reference call, because references are selected. You are about to hand them a free, unselected data point.

So behave the way you'd want your implementation team to behave. Calm, specific, no blame, a clear next step with a time on it. If you do that, the honest read in the room shifts from "the product has a bug" to "these people don't panic." I would rather buy from people who don't panic.

When someone uses it against you

Sometimes there's one person on the call who has been waiting for exactly this. "So does this happen in production?" said with a small smile to the rest of the committee.

Don't get defensive and don't oversell the distinction. The answer is short and it concedes the real point:

"Fair question. That's our shared demo environment, which is not the production architecture — but you have no reason to take my word for that, so here's what I'd suggest. Let me send you our status history and put you on a call with a customer who's been live for a year, and you can ask them what breaks and how often."

You have refused to bluff, and you have converted their scepticism into two commitments that both work in your favour. Reference calls where the buyer sets the agenda are more persuasive than reference calls where you do.

This is the same posture the clinical operations demo script takes with buyers who came specifically to find the cracks: you don't argue with the doubt, you give it somewhere productive to go.

Finish the meeting you came to run

After the switch, keep the original agenda. Do not shorten the call out of embarrassment. Do not offer to "just reschedule the whole thing" — that hands back the time you fought to get, and rescheduled demos slip.

Do re-cut what you cover. If the broken piece was one of four things, cover the other three live and put the broken one on the fallback path. If the broken piece was the whole story, run it on the fallback and spend the recovered time on discovery you didn't get to. Ask the questions you'd normally have to save for a follow-up: what does this workflow cost you today, who else has to sign off, what happened with the last tool you tried here.

And get the close right at the end. The temptation is to end apologetically and vaguely. Don't. End the way you would have ended anyway, with a specific next step and named owners. If anything, the failure makes a firm close more important, because a firm close is more evidence that you are not rattled.

The follow-up: two hours, not tomorrow

Send the recap within two hours, while the call is still the thing they're thinking about. Not the next morning. The gap between the failure and your response is itself a message about your response times.

What goes in it. First, a one-line, unflinching acknowledgement — "the account view errored out in our demo environment today" — because if you write around it, everyone notices you writing around it. Second, the content they missed, in whatever form you have: the deck, the recording, a short Loom you record yourself after the call showing the working flow. Third, the answers to any questions you took away. Fourth, the next step you already agreed, with a date.

What does not go in it. A long explanation of the root cause. Nobody outside your engineering team wants the root cause, and a detailed one signals that you have been thinking about your problem instead of theirs. One clause is plenty.

Why "let's re-demo it" is usually the wrong ask

The instinct after a broken demo is to ask for another demo. Resist it, most of the time.

A re-demo asks the committee to reassemble, which is expensive and which they will resent slightly, and it frames the next meeting around your problem rather than their decision. Worse, it resets the deal. You had momentum toward an evaluation and now you have a do-over of a meeting they already sat through.

Send the recording instead, individually, and ask for the meeting you actually wanted next. If the natural next step was a technical deep-dive with two of their engineers, ask for that and show the broken flow live at the start of it — same proof, smaller room, and the deal keeps moving forward instead of sideways.

The exception is when the broken feature is the deal. If the thing that failed is the one capability that differentiates you and the whole evaluation turns on it, then yes, get in front of them again — but ask for a short, tightly scoped session with a clear purpose, not "the demo again." Fifteen minutes, one flow, and you personally have tested it end to end within an hour of the call. The scripts written for buyers who have already killed vendors, like the healthcare demo script for a CMIO, are built on the same idea: narrow the ask, make it easy to say yes to, and let the proof do the persuading.

Rehearse the break

Last thing. Every rep rehearses the happy path. Almost nobody rehearses the failure, which is strange, because the failure is the harder performance.

So rehearse it. Have someone kill your screen share mid-sentence, or tell you the data didn't load, and practise the first sentence and the twenty-second count and the transition line until they're automatic. They need to be automatic, because the moment it happens live your heart rate goes up and you will say whatever is most available — and if the most available thing is nervous narration, that's what comes out.

This is exactly the kind of thing I built DrillCall for: reps running the same hard moment over and over against an AI buyer who pushes back, until the calm version is the reflex rather than the aspiration. If I were coaching a demo-carrying team this quarter, that's where I'd spend the reps — not on the perfect run, which takes care of itself, but on the eight or nine ways the call can go wrong and the twenty seconds after each one.

Because the demo will break eventually. It breaks for everyone. The only variable you control is whether the room watches a vendor come apart, or watches one handle it better than the last three did.