A run of show template

A run of show is the document your crew works from when something goes wrong. That is its real job. On a day where everything goes to plan it is a comfort; on the day the keynote speaker’s flight lands late, it is the difference between an adjustment and an unravelling.

It is not the attendee schedule. Attendees see times and rooms. The run of show holds the cues, the handovers, and the names.

The format

One row per action. Six columns. Nothing else.

Time	Duration	What happens	Owner	Cue	Notes

Time is a real clock time, not an offset. “09:15” not “T+15”.

Duration is how long the action takes, which is how you find out that your five-minute transition needs eight.

What happens is a specific action with a subject and a verb. “Priya opens doors to the Windsor Suite” rather than “doors”.

Owner is one person’s name. Not a team, not a role. One name.

Cue is what triggers it: a clock time, the end of another row, or a call from a named person.

Notes is where the exception lives: what to do if the speaker is not there, where the spare mic is, the phone number for the venue duty manager.

A worked morning

Day one of a two-day conference, 500 attendees, single main room plus three breakouts.

Time	Dur	What happens	Owner	Cue	Notes
06:45	15	Sam and venue open loading bay, crew badges issued	Sam	Clock	Venue duty manager: 07xx-xxx-xxxx
07:00	60	AV: comms check all four rooms, mics tested with PA live	Dana	Clock	Radio channel 2
07:30	30	Registration desk built, four scanners tested on a live badge	Priya	Clock	Spare scanner in flight case 3
07:45	10	Test push notification to crew phones only	Alex	Clock	If not delivered, escalate before 08:00
08:00	45	Registration opens	Priya	Clock	Two staff on app installs, not scanning
08:15	5	Keynote deck loaded to machine 2, confidence monitor confirmed	Dana	Deck received	Backup on USB, taped to lectern
08:30	10	Speaker escort meets keynote in green room	Sam	Clock	If absent by 08:40, go to plan B in notes
08:45	5	Morning notification sent: today at a glance	Alex	Clock	Pre-written, scheduled
08:50	10	Doors open to main room, walk-in music up	Priya	Sam’s call	Hold if registration queue over 30
09:00	5	Chair opens: welcome, app mention, first poll	Chair	Clock	Poll pre-loaded, Alex launches
09:05	40	Keynote	Dana on AV	Chair hand-off	Q&A queue opens at start
09:40	5	Moderator hands top three questions to keynote	Rae	09:40 exactly	Merge duplicates before handing over
09:45	10	Q&A	Rae	Keynote ends	Read each question aloud
09:55	5	Chair closes, signposts breakouts by room name	Chair	Clock	Room names as on doors
10:00	25	Break. Coffee in atrium. Photo album seeded	Alex	Clock	10 photos before mentioning it
10:05	10	Breakout rooms reset: mics swapped, slides loaded	Dana	Break starts	Three rooms, two crew — sequence in notes
10:20	5	Moderators in position, Q&A queues opened	Rae	Clock	One moderator per room
10:25	5	Doors to breakouts	Priya	Dana’s call
10:30	45	Breakout session 1, three tracks	Dana	Clock

Two things that row set demonstrates. The transitions have more rows than the sessions do, which is correct because that is where events break. And every row has a name, including the ones that look obvious.

Rules that make it work

One owner per row, always. Shared ownership is how a row gets skipped by two people who each thought the other had it. If two people are genuinely needed, write two rows.

Transitions get more detail than content. A 40-minute keynote is one row. The five minutes before it are six rows. Nothing goes wrong during the keynote that the run of show can fix; everything goes wrong in the transition.

Write the exception in the notes column. “If the speaker is not in the green room by 08:40” is worth more than the entire happy path, because the happy path does not need a document.

Real clock times. Durations are for planning; clock times are for running. A crew member glancing at a phone needs to compare two numbers, not do arithmetic.

One document, one author. Everybody contributes; one person holds the pen and publishes versions. Two run of show documents is worse than none, because both will be wrong and each holder will be confident.

Print it. The day it matters is the day the Wi-Fi is unreliable. Print the final version the night before, on paper somebody can annotate. Version-stamp it with a date and a time so nobody works from yesterday’s.

Include phone numbers. Venue duty manager, AV lead, catering, the vendor’s support line. On the document, not in somebody’s contacts.

What belongs in it that people leave out

• Registration desk staffing, including who helps attendees install the app rather than scanning badges.
• Notification sends, with who presses the button and whether the copy is pre-written.
• Schedule changes: who edits the app, who sends the notification, in that order.
• Moderator positions for every session that has Q&A.
• Photo album moderation at each break.
• The shoulder days. Setup and derig are part of the show and are where injuries and overruns happen.
• Meal breaks for crew. They are not optional and they are always the first thing dropped.
• The last row of the day, which is somebody locking something.

The relationship to the app

The app holds the attendee schedule. The run of show holds the crew’s cues. They share the public times and nothing else, and they diverge the moment something moves.

So the run of show needs a standing row for that: when a session changes, one named person edits the app, then sends the notification, in that order. Editing without notifying leaves attendees walking to the old room. Notifying without editing leaves the app contradicting itself. Both happen, and the fix is a row with a name on it.

The same applies to the check-in desk. If the arrivals count is being watched from the console, put a row on it: who looks, when, and what they do if the number is far from expectation. In event67 that is the live arrivals count against the guest list, and the usual reason for a gap is a scanner problem rather than an attendance problem — which is worth knowing at 09:10 rather than at lunch.

The version each person actually carries

One document, one author, and then three views of it, because a fifty-row sheet in somebody’s hand at 08:40 is unusable.

The full document lives with the producer. Everything, every row, printed and annotated.

A role card goes to each crew member: their rows only, in time order, on a single side of paper, with the two phone numbers they might need. Somebody running audio in one room needs eleven rows, not the whole show.

A public-facing one-pager goes to the registration desk and the chair: the attendee times, the room names as signposted, and who to fetch when something is wrong.

Cutting the role cards from the same source is what keeps them honest. Retyping them is how one crew member ends up working from an earlier version, which is the single failure this document exists to prevent.

Version-stamp all three with the same date and time in the footer, and reprint all three together or none of them. If a change lands after printing, announce it aloud at the crew briefing rather than reprinting one card, because a room with two paper versions in it is worse than a room with one slightly stale one.

Rehearsing

Read-throughs in an office find perhaps a third of the problems. Walk it in the room, with the crew who will do it:

1. The morning transition. Doors, first session, first Q&A hand-off.
2. The break reset. Three rooms, two crew, in twenty-five minutes. This is the one that fails.
3. One failure. Pick one: the deck does not load, the mic dies, the speaker is late. Run it. The point is not to solve it in advance; it is to find out who moves.

Twenty minutes of walking the transitions is worth an hour of reading the document.