How to Make a Run of Show (Step by Step)

The short version

A run of show gets made in two phases most guides only cover the first half of: building the document, and then actually running the event off it. Building it means listing every segment in order, timing each one by duration rather than a fixed clock time, assigning an owner to every row, attaching the cues and notes the crew needs, and padding the schedule with buffer before you ever share it. Running it means using that same document live, so when something inevitably slips, the times downstream update on their own instead of someone retyping a column by hand mid-show.

Most how-to guides for building a run of show stop at “now you have a document.” That's step 6 of 7 below. The step that actually determines whether the thing survives contact with a live event is step 7.

The 7 steps

1. List every segment

Start with a flat, ordered list of everything that happens: walk-in, welcome, speakers, breaks, changeovers, Q&A, closing. Don't worry about exact timing yet, just get the sequence right. It's easier to see a missing changeover or a segment in the wrong order in a plain list than once the columns are full of numbers.

2. Set durations, not fixed clock times

This is the step most templates get wrong, and it's the single biggest reason run of shows fall apart live. Give every segment a duration(“25 min,” “0:10”) rather than typing in a fixed start time (“9:35 AM”). A fixed time looks more precise on the page, but it's a number that has to be manually correct forever. A duration is the number that actually gets edited during prep, and it's the number a live tool can compute the rest of the schedule from.

Concretely: if you type “9:35 AM” into ten rows and the keynote before them runs 10 minutes long, all ten of those times are now wrong, and nothing about the document tells you that until someone notices in the room. If instead every row has a duration and the start time is computedfrom the row above it plus its duration, one edit, changing the keynote's actual duration to 35 minutes, pushes every following start time automatically. This is the difference between a document you have to babysit and one that reflows on its own.

3. Add an owner or department to every row

Every segment needs a name attached: AV, stage management, a specific speaker, catering, front of house. A row without an owner is a row nobody feels responsible for running on time. This is also what makes the document useful to more than one person, each department can scan the list for just their rows instead of reading the whole thing top to bottom.

4. Add cues and notes

Next to each segment, note what the crew needs to know while it's happening: mic count, lighting cue, video playback trigger, “hard out, do not let this run over.” Keep cues attached to the row they belong to rather than in a separate cue sheet or lighting doc, a cue that lives somewhere else gets checked late or missed entirely.

5. Build in buffer

Every run of show slips somewhere. Add a short buffer block every 3-5 segments (a break, open remarks, anything genuinely flexible) so a small overrun upstream has somewhere to be absorbed instead of cascading into everything after it. Then set one fixed hard-out, a real constraint like a venue booking or livestream window, that the whole day is built backward from. Buffer without a hard-out just delays the same problem to the end of the day.

6. Share it with the crew

The document only works if everyone running the show is looking at the same version. Send the current one, not an earlier draft that's been sitting in someone's downloads folder, and make sure every department knows where to find updates, not just the original. A run of show that only the person who built it can see isn't a run of show yet, it's a plan.

7. Run it live and let the times reflow

This is the step almost every run of show guide skips: what happens once the event actually starts. A run of show isn't done being useful when it's finished being built, that's when it starts being used. As the show runs, segments finish early or late, and every fixed time downstream is either stale or has to be manually corrected by hand while the person doing the correcting is also supposed to be calling cues or running sound.

If the schedule was built on durations, running it live looks different: marking a segment done, or nudging its duration, recalculates every start time after it automatically, and everyone watching a synced screen, control booth, backstage, stage monitor, sees the update immediately instead of hearing about the delay secondhand over comms. That's the part a static document, no matter how well it was built in steps 1-6, can't do on its own.

Deciding what to actually do about a slip, cut a segment, eat into the buffer, push the hard out, is a judgment call for whoever's calling the show, not something software decides for you. How to call a show covers those calls in detail.

Worked example

Say you're building the run of show for a half-day conference. Steps 1-5 might produce something like this (see the full run of show template for the complete populated example and column-by-column breakdown):

Now say the keynote runs long, 35 minutes instead of 25. On a fixed-time document, someone has to manually retype changeover and the coffee break's start times, and anyone who's already glanced at the printed sheet is working off stale numbers. On a duration-based one, changing the keynote's duration to 35 minutes pushes changeover to 10:10 AM and the coffee break to 10:20 AM on its own, and the buffer block does exactly the job it was built for: it absorbs the slip instead of pushing it into the rest of the day.

Steps 1-6 are the same whether you build the document in a spreadsheet or a purpose-built tool. Step 7 is where a spreadsheet stops helping, it has no way to compute anything or push an update to anyone else's screen. Runsheet is built around exactly that gap: you build the rundown on durations, then run it live with the times reflowing automatically and every connected screen, control, crew, stage, staying in sync.