Prepare a Demo Fallback That Still Answers the Question

The demo breaks mid-sentence. The screen that was supposed to show a request moving from submission to approval is showing a spinner, or a login page, or nothing. What you need at that moment is not "something to show." It is the specific part of the evaluation you can still deliver, plus a plain statement of the part you can't.

That is the whole shape of a fallback. You pick the substitute by working backwards from the question your audience came to answer, you keep the substitute's provenance attached to it, and you say out loud what has stopped being live. The alternative to a good fallback is a bad one: ten minutes of debugging with an audience watching, or a recording narrated as though it were happening now.

Separate the questions a live demo answers

A live demonstration looks like one activity and is actually several. When it fails, you lose some of them and keep others.

Understanding the workflow. What steps exist, in what order, who does what, what the screen looks like at each stage. This is the most portable. A recording carries it well.

Watching the current environment respond. Not that the product can do this, but that it is doing it right now, on today's version, at today's speed, over today's connection. This is the least portable. Nothing short of a live route establishes it.

Entering new data. The buyer supplies an input you did not choose — their cost centre code, their approver hierarchy, an obviously malformed entry — and everyone watches what comes back. A prepared backup contains only inputs you already chose. It cannot answer this.

Checking an integration now. Whether the connection to their HR system, their identity provider or their ticketing tool is live and behaving today. Another thing only a current route can show.

So the first move is to name the passage. Not "the demo," but the one stretch of the demo that carries the audience's question. If the question is does a submitted request actually reach the right approver and change status without anyone hand-carrying it, the passage is the sequence from submission through the approver's decision to the resulting status. That sequence is what has to survive.

Match the backup to that passage

Three shapes of fallback are usually available, and they preserve different things.

A recording when order and timing matter. It can show that the step happened after the previous step, that the approval appeared in a queue, how long the interval looked. Keep its date, product version, environment and any staged element attached to it.

Selected stills when the meaningful states are the point. Three stills of a submission form, an approval screen and a request list can show that those screens exist in that form. They cannot show order. Shuffle them and nothing breaks, because they never carried sequence in the first place. That is their limitation and also their useful property: they survive almost any delivery failure, including one that prevents video playback.

A spoken walkthrough when nothing visual is available. Describe what you would have shown, in the order you would have shown it, and say that it is a description.

Whichever you choose, keep the setup facts with it. A recording made in a demo tenant with a fictional employee and a prepared approver account is a real recording of a real workflow in a stipulated setting. That sentence belongs in the caption, not in your head.

And do not assemble a fallback from mismatched materials. If the submission screen is from version 4.2 and the approval screen is from 4.3, you have two screenshots, not a demonstration. A backup that quietly stitches states from incompatible versions claims a continuity that was never observed.

The labeling discipline here is close to something service designers already practise. GOV.UK's service manual guidance on making prototypes, in the section on types of prototype and code prototypes, is about being accurate about what a representation is and is not — a point checked in September 2026 and limited to UK government service design. It is a useful starting point for honest labels. It is not a fallback procedure, and it does not tell anyone which substitute will work in a commercial sales meeting. General demo-day presentation advice, such as the widely cited Y Combinator guide, tends to cover rehearsal and pacing on the live route; I have not inspected it here, and by its nature it does not address substitution. The method below is a practical proposal, not a sourced standard.

Decide the switch before you need it

A switch condition has to be observable. "If something goes wrong" is a mood, not a condition. Something more like: if the demo environment is not reachable two minutes after I open the request form, I stop trying and switch.

Choose the dependency you actually expect to fail — the venue's network, a login that may need re-authentication, a service you do not control — and write the condition against that. Two minutes is not magic; it is a limit you set in advance so the decision does not have to be made in front of an audience. Tell one other person the condition and the plan, so a colleague can prompt you if you drift past it.

Two failure modes to avoid at the switch point. The first is spending the meeting debugging. The people in the room came to evaluate a workflow, not to watch you re-seat a connection. The second is hiding the switch, whether by narrating a recording as if you were clicking now, or by implying that a prepared result was generated live. The first costs everyone's time; the second costs the evaluation its integrity, and it is the kind of thing a buyer notices and remembers.

Say what changed, in a few sentences

The transition should be short and factual. It needs four things: what is unreachable, what the substitute is, what it therefore cannot establish, and when the outstanding check will happen.

A script for the fictional case below might run: "The demo environment isn't reachable from this network, so I'm switching to a recording instead of debugging on your time. It was captured on 14 May in version 4.3, in a demo tenant with a made-up employee and approver. What it shows is the real sequence — submission, approval, status change. What it can't show is today's environment responding, so I'm not going to pretend otherwise. If you want the live check, we can do it Tuesday from your office."

Four sentences. No apology spiral, no invention.

A worked example, constructed rather than observed

The following situation is invented to make the choice concrete. Nothing here has been recorded, opened or rehearsed for this article.

A team is selling approval software to a buyer who currently routes purchase requests by email. The buyer's question is whether a submitted request reaches the right approver and updates its status without manual handling. The live demo has three steps: the presenter submits a purchase request for a fictional employee, an approver account approves it, and the request list shows the new status.

The presenter has two backup assets, both dated 14 May, both from version 4.3, both made in the vendor's demo tenant. A recording covers all three steps at real speed. A set of three stills covers the same three states as images.

Two minutes into the demo, after the request has been submitted and before the approval step, the presentation network drops. The submission already happened live and the audience saw it. Everything after it is now unavailable.

The presenter switches. The recording is the right asset here, because the buyer's question is about movement — does the request travel, does the status change, is there a gap where a person has to intervene. Stills cannot carry that, since three images in any order show three screens rather than a sequence. The presenter plays the recording from the start, skipping nothing, because the unbroken sequence is exactly the property that makes the recording the better substitute. It takes a couple of minutes; that is what the switch costs.

Afterwards the audience knows more than they did. They have seen the workflow end to end, in a dated version, in a stipulated setting. What they have not seen is today's environment carry the request through approval: the submission ran live and they watched it happen, but everything from the approval step onward came from 14 May. They also have not seen anything the recording did not contain.

Then the buyer asks the question that neither asset answers: what happens if the cost centre code on the request doesn't exist? The recording contains one predetermined input. The stills contain the same input. Neither can say. The honest answer is that it stays open, and the arrangement is to test it on a live system — the buyer's own, ideally — rather than to guess from a prepared run.

Notice how the two assets compare while both remain usable:

The stills are not wasted. As the second-order fallback when playback itself fails, or as a handout the buyer can keep, they do a job the recording cannot.

Rehearse the route, not the product

Owning a backup file is not the same as being able to use it. The rehearsal that matters is the delivery route: open the recording or the stills in the environment you will actually present from, on the machine you will actually use, with the projector or screen share you will actually have.

Test it with the dependency absent. If the venue's network is the thing you expect to fail, turn off the network and confirm the asset opens anyway. Check that the details are readable from the back row, that the sound works if the recording has narration, and that you can get from the end of the playback back to the decision question without fumbling.

Be clear about what this proves. A rehearsal shows that you can reach the asset and that the room can see it. It says nothing about whether the product works. Those are separate claims, and the second one is precisely what the fallback cannot settle. Do not let a successful rehearsal drift into sounding like evidence of reliability.

One more discipline worth keeping: a fallback should not quietly become the default. If the recording plays every time because the live route is never quite trusted, then the interactive claim was never really tested, and the audience may believe they watched something they didn't. The recording is a recovery route. It is not a substitute for being ready to answer the question live.

Keep the outstanding question visible

The end of a fallback is not "and that's the demo." It is the point where you say what remains unsettled and how it will be settled.

If the audience needs to evaluate a live response, a current permission boundary, or how their own data behaves, that check is outstanding. Name it, and arrange it — a follow-up session, a sandbox with real configuration, a trial in their environment. A prepared backup cannot repair a product that was never able to answer the question; it can only stop the meeting from pretending otherwise.

What to carry into the room, then: the asset itself, matching the passage you need to preserve. The switch condition, written down, with the dependency it guards against. Four sentences of disclosure for the moment you use it. And the one question you already know the backup cannot answer, along with where and when it will be answered instead.

That is enough. A fallback is not a second demo. It is the part of the evaluation you can still deliver, with the rest marked clearly as still to come.

Frequently asked questions

How should a presenter choose a demo fallback?

Start from the question the audience came to answer and the passage of the demo that carries it. Then match the substitute to what must survive: a recording when order and timing matter, selected stills when the meaningful states are the point, or a spoken walkthrough when nothing visual is available. Keep date, product version, environment, and any staged element attached.

What can a prepared backup not establish?

It cannot show today's environment responding, cannot accept new data the buyer supplies, and cannot show that an integration is live and behaving now. Those require a current live route. A recording or stills contain only inputs the presenter already chose.

When should the switch to a fallback happen?

Use an observable switch condition set in advance against the dependency expected to fail—for example, if the demo environment is not reachable two minutes after opening the request form, stop trying and switch. Tell one other person the condition and plan. Avoid debugging on the audience's time and avoid hiding the switch by narrating a recording as if it were live.

What should the disclosure say when switching?

In a few sentences, state what is unreachable, what the substitute is, what it therefore cannot establish, and when the outstanding check will happen. The sample script also names the recording date, version, demo tenant, and fictional users so the provenance stays attached.

Why can stills not replace a recording when the question is about movement?

Stills can show that screens exist in a form, but they cannot show order or timing; shuffled, nothing breaks. If the buyer's question is whether a request travels and changes status, the recording is the better substitute because it carries the unbroken sequence. The stills remain useful as a second-order fallback when playback fails, or as a handout.