How we work

When something goes wrong at an event, and what to do

An awards night at full tilt, a lit stage gantry reading AWARDS NIGHT above coloured wash lighting and a large group cheering on the floor

Something goes wrong at every event. Not most events, every one, including the ones that look immaculate from a seat in the third row. A speaker lands late. A radio mic dies in the middle of a sentence. A truck sits in the wrong loading bay. More people arrive than the kitchen was told about.

What separates a failure the room never notices from one it talks about afterwards is almost never the quality of the improvising. It is whether the response was decided weeks earlier, and whether one named person is allowed to act on it without calling a meeting first.

Can it be fixed on the day?

Mostly, no. By the time something has gone wrong the room is full, the schedule has no give left in it, and the people who could authorise a different plan are sitting at table two with a drink in their hand.

What you can do on the day is take an option that already exists. That is the whole trick and it is unglamorous. The recovery is not invented at 8.40pm, it is selected: somebody wrote it down while the event was still a document, it cost nothing to carry, and until this minute nobody needed it.

What actually goes wrong?

Five classes cover most of it. A person does not arrive, the technology stops, a supplier misses their slot, the headcount is wrong in one direction or the other, or the weather takes an outdoor element away from you.

They are not equally likely and they do not cost the same. They fail the same way, though: the first sixty seconds decide how much of it the room ever sees. Pick one.

Contingency picker

What you do immediately, what has to already exist for that to be possible, and whose decision it is.

A second option costs nothing until it is the only option. That is why it gets cut from plans, and why the plans that keep it are the ones that hold.

What goes in an event contingency plan?

One short entry for each of the five, written into the run of show rather than kept as a separate document nobody opens on the day. Each entry needs:

  • The trigger. What counts as it happening, and by when: the speaker is not in the building thirty minutes before their slot.
  • The fallback. What happens instead, in one line.
  • What has to exist first. The spare microphone, the second phone number, the indoor room held against rain.
  • Who decides. One name.
  • How the crew hears. On the radio channel, not by somebody crossing the room.

A risk assessment is the step before it: a list of what could go wrong, how likely each is and how serious, and a venue may ask for one with the build plan. The contingency plan is what you will actually do about each.

Who makes the call?

One person, named before the day, chosen by role rather than by seniority. The client is usually the worst candidate. Not for lack of authority, but because they are a guest at their own event and are three tables from where the decision has to happen.

The mechanism matters as much as the name. In a loud room a phone tree fails: you call someone, they do not hear it, you call the next person, and ninety seconds later two people arrive at different conclusions. A decision tree needs nobody to be reachable. Written into the run sheet as a plain if this, then that, and it is theirs, it survives a room at full volume. A conversation does not. Which jobs belong to whom is a question of its own, and it is where most of these failures actually start.

What is the five-minute buffer for?

Every run sheet worth reading carries deliberate empty lines. People take them for slack against overruns, and they do absorb overruns, but that is the smaller job.

A buffer is thinking time. It is the space in which somebody can spend thirty seconds deciding something, instead of deciding it while a segment runs over the top of them. Strip the buffers out and the schedule still works, right up until the first problem, after which every decision is made late and under pressure by whoever happened to be closest. The run of show is where a fallback becomes real, because a plan that lives in one person's head is not available to the person who finds the fault.

Does the audience notice?

Far less than you would expect, and not the thing you expect. A four-minute delay with nothing visibly happening reads as part of the evening. Three people in headsets crossing the front of the room quickly, one of them pointing, reads as a problem, and it lands harder than whatever the problem was.

So the response has a second half that is purely about behaviour. Nobody walks fast. Nobody announces what has broken. The emcee never says the word technical. And the room is given something to look at, even if that something is only the next item arriving ten minutes early.

None of this promises that nothing will go wrong. We run six kinds of event and things go wrong at all of them. What you are buying from anybody who runs events is that the second option was written down while it was still free, and that one person in the room is allowed to reach for it. That is most of what running an event is.

Common questions

What should you do when something goes wrong at an event?

Take an option that already exists rather than inventing one. In the first sixty seconds, keep the visible part of the event moving: bring the next item forward, hand up the spare microphone, let the person on stage keep talking. Then pass the problem to the one person named in advance as the decision maker for that kind of failure. Almost nothing is genuinely solved on the day. What happens on the day is that a fallback decided weeks earlier gets selected.

Who decides what to do when an event goes wrong?

One named person per kind of failure, written into the run of show before the day. Technical faults belong to the AV lead. Changes to the running order belong to the event manager. Anything about the room, the covers or the service belongs to the venue's banquet manager. The client is usually the wrong choice, not for lack of authority but because they are a guest at their own event and are rarely near where the decision has to happen. In a loud room the mechanism matters as much as the name, so write the rule as a decision tree rather than a list of people to phone.

What is an event contingency plan?

A short list of pre-decided responses, each attached to a specific failure, each with a named owner and whatever has to exist in advance for the response to be possible. It is not a general document about risk. A usable contingency plan says which item moves forward if a speaker does not arrive, which microphone is already live if the first one fails, what time the wet-weather decision is made and who makes it. Most of it costs nothing until it is used, which is why it is the first thing cut from a plan and the thing whose absence is felt hardest.

What is the difference between an event risk assessment and a contingency plan?

A risk assessment lists what could go wrong, how likely each is and how serious, and a venue may ask for one with the build plan. A contingency plan is the next step: for each risk, the trigger, the fallback, what has to exist in advance, and the one person who decides.

Ask us what we would do

Tell us what you are running and where it worries you. We will come back with a shape for the day, the fallbacks written into it, and an itemised quote you can read.