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

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.

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.

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.