How to Write a Production Handover That Any Team Can Run
A step-by-step guide to building production notes and a handover document so a colleague who was never in the room can run your live programme from the page alone.
Elena Brooks · · 7 minutes to read
Start with the reader who was not there
Before you type a single line, decide who will open this document. It may be a stage manager who joins on the morning of the show, a technician covering for a colleague who fell ill, or a producer taking over a weekly streamed discussion. None of them sat in your planning meetings, so none of them know why the second segment moved or why a particular guest must never be introduced first.
Write for that person at half past seven in the morning, with a coffee in one hand and about ten minutes to read. This gives you a useful test: if a sentence only makes sense to someone who attended the meetings, it does not belong in the handover as written. Rewrite it so the reason travels with the instruction.
In my own work on concerts and corporate shows, the handovers that failed were never short of facts. They were short of order. The reader had to hunt for the start time, the venue contact and the fallback, and every minute of hunting was a minute not spent preparing.
- Name the likely reader and what they already know
- Keep the first page readable in about ten minutes
- Give reasons next to instructions, not in a separate history
Build the one-page summary first
Every handover should open with a single page that answers the questions people ask in the first five minutes. What is the programme, when does it start, how long does it run, where is it, and who is the one person to call if something goes wrong. Put the running order's headline structure here too: the number of segments, the total running time and the hard stop.
Resist the urge to be clever with layout. A plain table with segment number, start time, length, owner and one line of content reads faster than any designed page. Presenters glance at it between segments, and technicians glance at it with gloves on or headsets half off.
Once the summary is done, test it by handing it to someone outside the project and asking them to tell you back what happens at the halfway point. If they hesitate, the summary is still carrying your assumptions rather than your plan.
- Programme name, venue or platform, start time and hard stop
- One named contact for decisions during the show
- Segment table with owners, not just titles
Write production notes that explain the why
Production notes are the layer beneath the summary. They hold the detail a rundown has no room for: where each presenter prefers to stand, which remote guest needs a two-minute warning, how the lower-third graphics are called and by whom. Write them in short paragraphs under the segment they belong to, so the reader finds the note exactly where the problem might occur.
Be specific about decisions that were made and who made them. A line such as the panel closes early if the opening runs past minute twelve, agreed by the moderator, is far more useful than a vague note about being flexible. It tells the next person both the trigger and the authority to act on it.
Avoid private shorthand. Abbreviations that feel obvious after three rehearsals will baffle a newcomer, and a nickname for a camera position helps nobody who was not there when it was coined. Spell things out once and the document keeps working long after your memory of it fades.
- Place each note under the segment it affects
- State the trigger, the action and who decides
- Spell out every abbreviation the first time
Record the fallbacks while they are fresh
Most handovers describe the plan and quietly omit what happens when the plan breaks. Yet the next team will meet the problem on the day, usually with an audience watching. For each segment ask what is most likely to go wrong and write down the agreed response before you forget the conversation that produced it.
Typical entries are modest. A remote guest drops from the call, so the moderator moves to the prepared question set and the producer retries the link twice before cutting. A presenter runs long, so the closing segment loses its second item. A video clip fails to play, so the host speaks over a still image. None of this is dramatic, and all of it saves a nervous minute.
Keep fallbacks short and ordered by likelihood. A reader scanning mid-show wants the first response immediately, not a paragraph of options. If a fallback needs a long explanation, put the explanation in the notes and a single line in the rundown.
- One likely failure per segment, one first response
- Note the point of no return for each decision
- Mark any fallback that needs a call to someone
Test the document before you hand it over
A handover is not finished when you stop writing; it is finished when someone else can use it. Ask a colleague who has not seen the programme to read it and run a spoken walkthrough from the opening cue to the final credits. Watch where they pause, because every pause marks a gap in what you wrote.
Fix those gaps straight away, then read the document once more as if you were the presenter rather than the producer. Presenters care about what they say and when they stand, not about camera routing. If the document speaks to both groups without confusing either, it is close to ready.
Finally, date every version and say which one is current. Two copies in circulation with different timings is one of the commonest and most avoidable sources of confusion on the day itself, particularly when a late change arrives after the printed copies have gone out.
- Have a newcomer talk through the show from the page
- Label versions clearly and retire old copies
- Check the document reads sensibly to presenters too
Keep the handover alive after the show
The strongest handovers are updated after each programme, not written once and shelved. In the days following a show, add what actually happened: the segment that overran, the cue that was missed, the fallback that worked better than expected. Ten minutes of honest notes now spares the next team a repeat of the same surprise.
This habit also builds a record that makes the next planning round quicker. When a similar programme comes up in these autumn weeks or any other season, you start from a tested document instead of a blank page, and the timings you adjust are grounded in what really took place rather than what you hoped would.
Treat the notes as a shared working file. The more people who feel able to add a line, the more complete it becomes, and the less any single person's absence can disturb the programme.
- Add a short after-show section within a few days
- Update timings with what actually happened
- Let the whole team contribute corrections
A good production handover is a short summary, honest notes, ordered fallbacks and a final test with someone fresh. None of it needs special software, only the discipline to write for a reader who was not in the room. Build the summary first, explain your reasons, record what could go wrong, and update the file after every show. Done this way, any capable team can pick up the programme and run it calmly from the page.