You are mid-demo and the product fails in front of the customer. What do you do, and what do you do afterwards?

The first ten seconds set the price of the whole incident

Everyone in the room can see the screen. The failure is not a secret you might get away with, so the only variable is whether they watch you handle it well or watch you pretend. Say what has happened, in plain words, within a couple of seconds: name it, say what you are going to do about it, and keep talking. Silence with a spinning screen is what does the damage, because for fifteen seconds the room's attention moves from your product to your composure and finds nothing there.

Two reflexes to suppress. The first is clicking repeatedly and quietly in the hope it comes back, which reads as panic and usually makes the state worse. The second is blaming the network or the VPN before you know, because if it later turns out to be a product defect you have converted a technical problem into a credibility problem, and the technical evaluator in the room — who has watched vendors do this for years — will already have noticed.

Work out which of three failures it is, quickly

The response differs by cause, and you usually have enough information within seconds.

A demo environment or connectivity problem is the most common and the least serious: a sandbox someone reset overnight, an expired token, a slow tunnel. It is genuinely not about the product, and you may say so — once you are sure — as long as you say it without relief in your voice.

Your own driving error is the second, and it is the easiest to recover if you own it immediately and without theatre. "That is me, I have filtered the view — one second." A candidate who admits this crisply scores better than one who pretends the product behaved oddly, and interviewers watch for exactly that substitution.

A genuine product defect is the third, and it is the only one with lasting consequences. If a feature you claimed works does not, that is now the most important thing you learned in the meeting, and it must be reported inside your own organisation and to the customer in writing. Do not decide live that it is an environment issue because that is the comfortable explanation.

Roughly what you say

The specific wording matters more here than in most parts of the job, because the room is reading tone as much as content.

Weak:   [silence, refreshing]  "...it's usually much faster than this."
Weak:   "That will be your network, it works fine in our environment."

Better: "That has not loaded and it should have. Give me one attempt at it -
         I am checking whether our sandbox has dropped its session, which
         happened to us on Tuesday. If it has not come back in thirty seconds
         I will show you the same flow from a recording and we will come back
         to it live."

If it is a real defect:
        "I am going to stop guessing. That is not behaving the way I told you
         it would, and I would rather find out why than talk over it. I will
         have an answer to you today, including whether it is a defect or a
         limitation, and I will be straight with you either way."

That last construction is the one senior candidates use, and it works because it commits to an answer and to honesty about the outcome without promising a fix nobody can promise yet.

One narrated attempt, then route around

Give yourself a single attempt of thirty to sixty seconds, narrated so the room can follow what you are doing, and then stop. Beyond about a minute you are debugging in front of an audience, and the meeting quietly becomes about your infrastructure instead of their problem.

Then route around it and protect the purpose of the meeting, which was never "see feature seven work". Move to the next part of the flow, use the recorded fallback you prepared, or step off the screen entirely and talk through the outcome on a whiteboard with the customer's own numbers. A demo that loses one component but reaches its point still advances the deal. A demo that spends twenty-five minutes on a broken screen has cost you the slot and the narrative.

Whatever you skip, say you are skipping it and that you will come back to it. Quietly avoiding the feature that failed is noticed by exactly the person you most need to convince.

Afterwards, the same day

Write to them before the day ends, and keep it short and specific: what failed, what you have established about why, whether it is a defect or a limitation, what you are doing, and a named date for the re-demo. The email is doing something a verbal reassurance cannot, which is giving your champion a document they can forward to the sceptic who was in the room and will raise it in an internal meeting you are not attending.

Then use the specificity as an advantage. "The report timed out because our demo tenant was rebuilt on Tuesday with a fraction of the data volume; here is the same report against a full-size dataset, recorded this afternoon, and here is a sandbox login if you would rather run it yourself" converts a failure into evidence. Recovery handled well is more persuasive than a demo that never broke, because the customer now has a data point about how you behave when something goes wrong — which is the thing they are genuinely trying to predict, given they are about to depend on you for three years.

If it was a real gap, say so and do not soften it into a roadmap implication. Report it internally with the account attached, get a factual answer on whether and when it will be fixed, and pass on only what your product organisation will stand behind in writing. A dated commitment you invented to save a meeting becomes a contractual expectation, and it will be quoted back to you by someone holding a purchase order.

Then fix the cause on your own side

The internal half is what separates someone who recovered from someone who will recover again. Demo environments break because they are shared, unowned and rebuilt by whoever needs them. That is an operational problem with operational answers: a checked pre-flight, a recorded fallback for every flow you claim, data volumes that resemble production, and an environment that is not being reset by another team an hour before a customer call.

• Run the exact flow end to end within an hour of the call, on the same network you will use.
• Keep a recording of every flow you might show, current enough to be honest.
• Know which two features are fragile, and have a decision made in advance about whether you will show them at all.
• Have a second path to the same story: a whiteboard version you can deliver with no software at all.

The reputational arithmetic people get wrong

Candidates assume the demo failure is the damaging event. It usually is not. Customers know software breaks, and most evaluators have themselves demonstrated something to their own board and had it fail. What they remember is the explanation — specifically whether it turned out to be true. A vendor who blamed the network and was later found to have hit a real product limit has taught the customer to discount everything else they said, and that discount applies to the estimate, the architecture and the reference calls.

So the reason to be honest in the moment is not principle, it is arithmetic: the cost of a broken feature is bounded and usually small, while the cost of a discovered untruth is applied to your entire proposal. That is the calculation an interviewer is checking you have made, and it is why "I would tell them straight away and follow up in writing the same day" is a stronger answer than any recovery trick.