What's the difference between a run of show and an agenda?

An agenda lists what happens. A run of show adds when, how long, who runs it, and what cue triggers the next thing — it's built to be executed live, not just read.

What software should I build a run of show in?

A spreadsheet works until the show goes live and times start slipping. At that point you're manually re-typing every start time by hand, live, under pressure. Purpose-built tools reflow the times for you.

How much buffer should I build into a run of show?

Enough that a 2-3 minute slip on one item doesn't cascade. Common practice is a short buffer block every 3-5 segments, plus a fixed hard-out time the whole show works backward from.

Do I need a separate document for AV/tech cues?

No, and you shouldn't. Cues that live in a separate doc from the timing get missed. Put the cue in the notes column next to the item it triggers on.

Should every row have an owner?

Yes. A run of show without a dept/owner column turns into a document nobody feels responsible for executing on time.

What happens to the rest of the schedule if one segment runs long?

In a static document, nothing happens automatically, someone has to manually retype every start time after the overrun, live, while also doing everything else their role requires. In a run of show tool where start times are computed from durations, one edit reflows every following start time on its own, and everyone watching a synced screen sees the update immediately.

Run of Show Template: The Columns That Actually Matter

What a run of show actually is

A run of show (also called a rundown, show flow, or cue sheet) is the minute-by-minute schedule a live event runs on: every segment, its planned start time, how long it should take, who's responsible for it, and what cues or notes matter when it's happening. It's the document a show caller, stage manager, or AV lead has open the entire time the event is live.

The difference between a run of show and a plain agenda is that a run of show is built to be executed, not just read. An agenda tells an attendee what's happening. A run of show tells the crew when to be ready, what triggers the next cue, and how much room there is before the schedule is in trouble.

The columns that matter

Most working rundowns converge on the same core columns, in roughly this order:

Start time — when the segment is scheduled to begin. On paper this looks fixed, but in practice it should be a computed value: if an earlier item runs long, every start time after it needs to shift. A static, hand-typed start time is the single most common point of failure once a show is actually running.
Duration — how long the segment is planned to take. This is the number that actually gets edited during prep; start times should derive from it, not the other way around.
Item / segment— what's happening: “Welcome + opening remarks,” “Keynote,” “Panel: Q&A,” “Band changeover.”
Dept / owner— who's responsible for this segment: AV, stage management, a specific speaker, catering. Rows without an owner are the ones that get missed.
Notes / cues— 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.”
Color / status — a fast visual read for the room: this segment is talent-facing, this one is a hard deadline, this one is flexible.

Example: a half-day conference run of show

Start	Dur	Item	Dept	Notes
9:00 AM	0:30	Doors / registration	Front of house	House lights up, walk-in music
9:30 AM	0:05	Welcome + housekeeping	Host	Handheld mic, house lights to 50%
9:35 AM	0:25	Opening keynote	AV	Lav + confidence monitor, hard out
10:00 AM	0:10	Changeover	Stage	Reset to panel chairs, mic check x4
10:10 AM	0:40	Panel: industry outlook	AV	4 lavs, moderator has timer card
10:50 AM	0:20	Coffee break	Front of house	Buffer block, absorb overrun here
11:10 AM	0:35	Product demo	AV	Laptop feed to main + confidence screens
11:45 AM	0:10	Closing remarks	Host	Thank sponsors, exit music cue
11:55 AM	0:05	Hard out	All	Room must be clear by noon (next booking)

Notice the buffer block at 10:50 — it's not filler, it's the slack the rest of the day borrows from when something upstream runs long. And the last row isn't a segment at all; it's the constraint everything else is built backward from.

Common mistakes

Typed-in start times instead of computed ones. The moment one item overruns, every start time below it is wrong until someone manually retypes the rest of the column, live, mid-show.
No hard out. Without a fixed end constraint, a rundown has nothing to protect against, and every small slip just compounds.
Cues living in a separate document.A lighting or video cue sheet that isn't attached to the timing it belongs to gets checked late or not at all.
No owner column.If a row doesn't say who's responsible, it's nobody's job until it's already late.
One editable copy, no live sync.A spreadsheet on one laptop means the person calling the show, the AV desk, and the stage all have to be looking over the same shoulder, or working from a version that's already stale.

What happens when the show runs long

Every run of show slips eventually. Say the opening keynote above is scheduled for 25 minutes but the speaker runs 10 minutes over. In the example table, that means changeover, the panel, the coffee break, the product demo, closing remarks, and the hard out are all now wrong by 10 minutes, six rows someone has to manually retype, live, while also doing the rest of their job.

That retyping step is exactly what a run of show tool is supposed to remove. When start times are computed from durations instead of hand-typed, one edit to the segment that ran long reflows every start time after it automatically, and anyone looking at a synced screen, control, crew, or stage, sees the new times immediately instead of hearing about the delay secondhand.

Deciding what to actually do about the slip (cut a segment, eat into the buffer, push the hard out) is the show caller's job, not the software's. How to call a show covers those calls. Runsheetis where the reflow itself happens automatically once you're running the show live.

FAQ

What's the difference between a run of show and an agenda?: An agenda lists what happens. A run of show adds when, how long, who runs it, and what cue triggers the next thing — it's built to be executed live, not just read.
What software should I build a run of show in?: A spreadsheet works until the show goes live and times start slipping. At that point you're manually re-typing every start time by hand, live, under pressure. Purpose-built tools reflow the times for you.
How much buffer should I build into a run of show?: Enough that a 2-3 minute slip on one item doesn't cascade. Common practice is a short buffer block every 3-5 segments, plus a fixed hard-out time the whole show works backward from.
Do I need a separate document for AV/tech cues?: No, and you shouldn't. Cues that live in a separate doc from the timing get missed. Put the cue in the notes column next to the item it triggers on.
Should every row have an owner?: Yes. A run of show without a dept/owner column turns into a document nobody feels responsible for executing on time.
What happens to the rest of the schedule if one segment runs long?: In a static document, nothing happens automatically, someone has to manually retype every start time after the overrun, live, while also doing everything else their role requires. In a run of show tool where start times are computed from durations, one edit reflows every following start time on its own, and everyone watching a synced screen sees the update immediately.

Build the rundown. Run the show. Every screen in sync.

Runsheet is the hosted place to build a run of show and then run it live, no setup, share links for control, crew, and stage screens. Free for 1 rundown, 3 connected screens.

Start free