Handover Notes That Fail: Common Mistakes and How to Avoid Them
Most handover documents break down in the same few places. Elena Brooks walks through the usual mistakes in production notes and shows how to fix each one before the programme goes live.
Elena Brooks · · 5 minutes to read
Writing notes only the author can read
The most frequent mistake I see in learners' handover documents is shorthand that made sense at the desk and means nothing to anyone else. A note that says 'go on VT after Dan' assumes the reader knows who Dan is, what VT stands for on this particular show and what counts as 'after'. On the night, the person holding the page is often tired, standing in a dim corridor and reading by phone light.
The fix is simple but takes discipline. Read every line as if you were a technician joining the team an hour before doors. Spell out names with roles on first use, replace private abbreviations with plain words, and give each instruction one clear trigger. If a line needs a conversation to be understood, it is not yet a handover line, and it should be rewritten until it stands on its own.
- Name people with their role on first mention
- Replace private abbreviations with plain words
- Give every instruction a single, visible trigger
Burying the running order inside long prose
Some handovers read like a letter. Everything is there, but the sequence of segments is hidden in paragraphs, so a stage manager has to hunt for the next start time while the programme is moving. Prose is good for explaining intent, and poor for being scanned mid-show.
Keep the running order as a table or a clean list near the top, with start time, segment name, owner and duration in the same columns throughout. Put explanation underneath or on a separate page, so the live page stays short. In class we ask learners to hold the document at arm's length and see whether they can still find the next segment in three seconds. If not, the layout needs work before the content does.
- Place the sequence table at the front of the document
- Keep columns identical from page to page
Leaving out the fallback options
A handover that describes only the plan that is supposed to happen is half finished. Live programmes drift: a guest arrives late, a remote link drops, a segment overruns by four minutes. If the notes are silent on what to cut or swap, the person running the show must invent a decision under pressure, and that decision may differ from what the producer would have wanted.
For each segment that carries risk, write one fallback in a single line: what is dropped, what moves up, who approves it. You do not need a contingency for everything. Choose the three or four moments where trouble is most likely, state the agreed response, and note who has the authority to call it. That small addition turns a script into a working tool.
- Mark the riskiest segments first
- Say who is allowed to approve a change
Forgetting the people outside the room
Handovers often list the team in the venue and overlook contributors who are elsewhere: a remote guest, a presenter joining from another site, a caption operator working from home. Yet these are the people most likely to be left guessing, because they cannot lean over and ask a colleague what is happening next.
Include a short contact block with each remote person's role, the time they should be ready, the link or dial-in route they will use and a backup way to reach them. Add one sentence on how they will know it is their turn. When the notes cover everyone who touches the programme, the producer is no longer the only person who holds the full picture, which is the whole point of a handover.
- List remote contributors with ready times
- Record a second way to reach each person
- Say how each person will be cued
Sending the document too late, or never updating it
Even a well written handover fails if it arrives ten minutes before the show, or if three versions circulate and nobody knows which is current. Late changes are normal; unmarked changes are the problem. A presenter who rehearsed from one page and is handed another at the door will trust neither.
Pick one master copy and put a version label and a revision note on the first page, such as what changed since the last send and who was told. Agree a cut-off after which changes go by voice and are written into the master straight away. Early in autumn, when schedules fill and teams rotate quickly, this habit saves more confusion than any extra detail.
- Label the version on the first page
- Note what changed since the previous send
A short check before you hand over
Before sending any production notes, I run through a brief check. Can a stranger find the running order at once? Does each segment have an owner and a start time? Are fallbacks written for the risky moments? Are remote contributors covered? Is the version clear?
If the answer to any of these is no, fix that one point and ask again. Do not try to perfect everything at once. A modest, consistent document that people can actually use beats an elaborate one that nobody opens, and the check takes only a few minutes once it becomes routine.
Handover mistakes are rarely dramatic. They are small gaps: a private abbreviation, a missing fallback, a remote guest nobody wrote down. Each is easy to fix once you know where to look. Treat the page as the way the next person will run the programme without you, and write for that reader. Do that, and the notes will hold up on the night, whoever is holding them.
