A checklist to run through before commissioning live show runbooks
Before anyone writes a runbook, a few questions decide whether it will be used. A practical checklist for producers and technical leads weighing up live production workflow documentation.
Start with the show you actually run
The first item on any checklist is the programme itself. A runbook describes one kind of show, and the more precisely you can name it, the more useful the document becomes. A weekly studio magazine with three guests, a half-hour live discussion with remote contributors and a one-off stage event each need different pages, even if the same crew works on all of them.
Write down the format, the usual duration, the number of cameras, the sources feeding the gallery and the people who touch the show between doors opening and the final fade. If you cannot list those in a few minutes, that is already useful information. It tells you the knowledge sits in individual heads, which is exactly what documentation is meant to address.
Lighting is part of this picture too. Cue positions, preset states and who calls them often live in one person's memory, and they belong in the same description of the show as the camera plan.
- Name the format and its typical running time
- List every source entering the gallery
- Note who is on the crew and who covers absences
Decide what the document is for
Runbooks fail when nobody agreed on their purpose. Some are written to train newcomers, some to survive a handover, and some to settle arguments after a bad night. These are different documents, with different tone and level of detail, and trying to serve all three in one file usually produces something nobody opens.
Be honest about which problem is hurting most right now. If a freelance vision mixer has to be briefed from scratch every time, you need a clear pre-show sequence. If faults repeat because fixes were never recorded, you need a short section on known problems and their cures.
Choose a primary reader and write for that person. A secondary reader can be served later through an appendix or a one-page summary, but the main text should assume one reader who is competent, tired and short of time.
Check who will own it after it is written
A runbook is accurate on the day it is finished and begins to drift the following week. Equipment is swapped, a presenter changes, a route in the router is renamed. Before commissioning anything, decide who in your team will hold the master copy and who has the authority to change it.
Ownership does not need to be heavy. One named person, a simple version note at the top and a habit of updating after each show is usually enough for a small team. Without that, the document becomes a snapshot that people stop trusting, and a document people distrust is worse than none, because it gets followed in the wrong places.
Ask also where the document will live. A printed copy at the desk, a shared folder and a laminated card for the most critical steps all have their uses, and they should agree with one another.
- Name one owner and one deputy
- Put a version line and a date at the top
- Agree where the current copy is kept
Test the structure against a bad night
A good structure follows the order in which things happen. Preparation comes first, then line-up and checks, then the live running order, then a short section for faults, and finally close-down. Each part should be readable at a glance, because nobody reads paragraphs while a show is on air.
Before you accept a draft, imagine the worst realistic evening: a late guest, a dropped remote feed, a missing crew member. Walk through the document and see whether the person covering that role can find what to do within a few seconds. If the answer depends on knowing the show already, the draft is not finished.
Checklists work best when each line is a single action that can be ticked, with the person responsible shown beside it. Long explanations belong in a separate reference section that is read in advance, not during transmission.
Be clear about scope and effort
Documentation takes time on your side as well as ours. The person writing needs to watch a show being run, ask questions of each operator and read back drafts, and that means a few hours from busy people. Agree early who will be available and when, so the work does not stall waiting for answers.
Decide what is outside the scope. A runbook records how a show is run; it does not redesign the studio, retrain the crew or replace the manufacturer's manuals. Keeping those boundaries visible avoids disappointment when the finished pages describe the show as it is rather than as someone wishes it were.
Finally, ask for a draft stage. Seeing a rough version early, with gaps marked, is far cheaper than discovering at the end that a whole section was written for the wrong show.
- Allow time for observation and questions
- Separate documentation from redesign or training
- Review a rough draft before the final text
Questions to answer before you get in touch
If you have worked through the points above, you are in a good position to ask for help. A short note covering the show format, the crew size, the main source of trouble and who will keep the document afterwards gives enough to discuss scope sensibly and to receive a written quotation.
It also helps to gather what already exists: old run sheets, scribbled gallery notes, patch lists and any earlier attempts. These are rarely tidy, but they show what the crew actually relies on, and good documentation usually grows out of them rather than starting from nothing.
Treat the checklist as a filter rather than a hurdle. If several answers are still unclear, spend a week or two on them first. The eventual runbook will be shorter, sharper and far more likely to be used at two minutes to transmission.
Deciding on live production workflow documentation is mostly a matter of knowing your own show well enough to describe it. Name the format, pick a reader, settle who owns the pages, test the structure against a bad night and be realistic about the effort. With those answers in hand, a conversation about a runbook becomes short and specific, and the result is something your crew will reach for.
Get in touch
- Phone
- 01522 390417
- [email protected]