Common Mistakes in Live Production Runbooks and How to Avoid Them

A second mistake is treating the runbook as a place to store everything ever learned. Each fault that occurs gets a paragraph, each guest a footnote, and within a season the document runs to forty pages. In the gallery, with a live feed running, no one will search forty pages for the next step.

A working runbook has layers. The top layer is a single sheet: running order, key contacts, and the handful of checks that decide whether the show can go to air. Beneath it sit the detailed procedures, each short enough to read in a minute and each findable by a clear title.

Length is not the measure of care. A crew that can find the right instruction in ten seconds is better served than one holding a thorough manual they have quietly stopped consulting.

Studios change. A light gets moved to clear a new set piece, a mixer is replaced, a monitor is relocated, and the runbook goes on describing the old arrangement. The danger is not that it is wrong in one place but that the crew learns it cannot be trusted and starts relying on memory instead.

Out-of-date lighting notes are a good example. A cue sheet that refers to a fixture which no longer hangs above the set will confuse the operator and may lead to a rushed fix during rehearsal.

Give the document an owner and a rhythm. After each show, whoever ran the gallery spends ten minutes marking what differed from the page. Once a month, the owner folds those marks into a clean revision and replaces the printed copies so that old versions do not circulate.

Most runbooks describe a show that goes to plan. They list the start-up, the running order and the shutdown, then stop. Yet the reason a crew reaches for the document at all is usually that something has stopped behaving, and that is exactly where the page falls silent.

Add a short section for the faults that have actually happened in your own studio: a lost return feed, a talkback line that drops, a cue that fires late. For each, write what the operator sees, the first thing to check, and who to tell. Keep it to a few lines.

Be honest about limits as well. If the answer to a fault is to hand over to an engineer, say so plainly, with a name and a number. A runbook that pretends every problem can be solved at the desk encourages improvisation that makes the situation worse.

A runbook that has only ever been read at a desk has not been tested. Steps that look sensible on paper can turn out to be impossible in sequence: a camera move that needs a hand already occupied, a cue that lands before the operator has the right page open.

The remedy is a dry run in which someone follows the document literally, doing only what it says. Do this in rehearsal, with the real crew in their real positions, and note every point where they had to guess. Those guesses are the gaps.

Run it again after you correct them. It is tempting to treat the first round of fixes as final, but a second pass usually catches the awkward order of steps that the first correction introduced. Two honest passes are worth more than a polished document that nobody has ever followed.

Crews change. People move on, new juniors arrive, and a freelancer covers a holiday. A runbook that depended on the founding team's memory leaves the next group to rediscover the same lessons by trial and error, often on air.

Write with that future reader in mind. Record why a decision was made as well as what it is: why the stage left light stays low during the interview, why the talkback check comes before the audio check. A reason survives changes in equipment where a bare instruction does not.

Keep the finished runbooks together in one place that the whole crew knows, and agree how new starters will be shown it in their first week. Documentation only repeats reliable shows if it is found, read and used by people who were never there when it was written.