How to write a run of show for a live event
A run of show is the minute-by-minute document the production team delivers from. Here is the structure that works, the columns worth keeping, and the discipline that stops it drifting out of date before doors.
The short answer
To write a run of show: list every item in order, give each one a start time and a duration, name the owner and the department, and add the cues that make it happen. Then read it aloud, add the gaps you forgot — changeovers, walk-ons, buffers — and re-time from the end backwards against your hard stops. The document is finished when someone who was not in the planning can deliver from it.
The rest of this is how each of those steps tends to go wrong, and what to do instead.
Time it with durations, not fixed times
The most useful change you can make to a run sheet is to stop writing fixed clock times as the source of truth and start writing durations. A run of show built on fixed times has to be entirely rewritten every time something moves. One built on durations reflows.
Practically: a session is "45 minutes", not "09:30–10:15". The clock times are derived and displayed, but the duration is what you edit. When the keynote overruns by seven minutes, everything after it re-times itself and you can see immediately whether you still make the hard stop.
This is also the honest way to plan. Nobody knows that a panel will end at 11:04. Everybody knows it is about forty minutes.
Mark the things that cannot move
Every event has a small number of genuinely immovable moments, and a large number of things people talk about as though they are immovable. Separating them is most of the value of the document.
- Hard stops
- Venue curfew, broadcast window, a satellite slot, the moment doors must open. Miss these and there are consequences beyond embarrassment.
- Anchors
- Items scheduled around something external — a VIP arrival, a scheduled announcement, a partner session. Movable, but expensively.
- Soft items
- Everything else. This is where you find the minutes when the day drifts, and knowing in advance which items are soft is what lets you find them calmly.
Handling changes on the day
Assume the run of show will change after it is final. It always does. The question is only whether the change reaches everyone who needs it.
Two rules cover most of it. First, one editor: a single person makes changes during the show and everyone else raises them. Second, no side channels: if a change is agreed in a corridor or a group chat and not written into the document, it has not happened. Both are discipline rather than tooling, and both survive whatever you build the sheet in.
There is more on the propagation problem specifically in handling late running-order changes.
How EventBlok approaches this
EventBlok models durations rather than fixed times, so moving one item re-times the rest of the day and shows the projected finish against your hard stop as you edit. Cues sit beneath their session, and the prompter reads the same running order, so a script and a cue list cannot disagree about what is happening next.
The showflow view is where that running order is called from on the day.
Plan the event. Publish the programme. Run the show.
One event spine, many views. Build the programme once, then give every person the right live view of it.