Run-of-show templates we use for full-day corporate events

A run-of-show document is the single most important deliverable for a production team. It is the artifact that turns "the client wants to do an all-day summit with a keynote, three panels, breakouts, and a closing reception" into something a fifteen-person crew can actually execute.

After running enough events, we have settled into a format that works across most program types. This is what it looks like and why each piece is there.

The header

Every page of the document has the same header: event name, date, venue, top-level production contact, top-level client contact, and a version number. Run-of-show documents go through five to ten revisions before showtime, and people will end up with old versions on their phones. The version number is the only way to know what is current.

We also include the names and call times of every crew member, the load-in time, and the load-out time. That seems obvious until you watch someone show up an hour late because they assumed call time was the same as last year's event.

The columns

The body of the document is a table with five columns:

• Time, in 24-hour format, with minute precision
• Duration, in minutes
• Item, the human-readable description of what is happening
• Role, the production team member responsible for executing this moment
• Cue, the specific technical action

The Time column is what everyone reads first. The Duration column is what the producer reads to know whether the show is on schedule. The Cue column is what the audio, video, and lighting engineers read.

What goes in "Cue"

The cue column is where most run-of-show documents fall down. People write things like "speaker takes stage" or "lights down for video." That is not actionable. We write cues that an engineer can execute without asking:

• "LX cue 12 fade 5s, A1 unmute lav 4, V1 cut to camera 2"
• "VT cue 7 play full, music ducks to -20dB under voiceover"
• "Houselights to 30%, stage wash up to programmed cue 14"

The cue is the specific action, in the specific syntax that the operator uses. The producer's job is to translate the client's narrative into those cues. The engineer's job is to execute them. When the engineer has to interpret the cue mid-show, the cue is wrong.

Page breaks

A long event has too many cues to fit on one page, and that is fine. We break the document into program segments — Arrival, Keynote, Panel One, Networking Break, Panel Two, Closing — and let each segment start on a new page. The producer reads through the segment two minutes before it begins to refresh on the cues. The engineers do the same.

If a segment spans a page break, the engineers will miss a cue. They will look at the page they have, see no upcoming cue, and put their attention somewhere else. We do not let segments cross page breaks.

The buffer column

We add a sixth column on internal versions of the document, which we hide from the client: the buffer column. It marks moments where the program has built-in slack — usually three to five minutes — that we can absorb if a previous segment runs long. Knowing where the buffers are tells the producer when to slow down and when to gently cut a speaker short.

Most events run long. Buffers are how shows still end on time.

The post-event update

After the event, we annotate the document. Cues that were executed differently than planned get a note. Moments where we ran over or under get marked. The next time we run a similar event, the previous run-of-show is the starting point, not a blank page.

That accumulation of small notes is the actual institutional knowledge of a production team. The document is the artifact, but the annotations are what make the next event better than the last one.