If you’ve produced a corporate event, you’ve encountered a run-of-show. You may have approved one, complained about one, or been handed one on show morning that you barely had time to read. What you may not have had is a clear explanation of what the document is actually supposed to do, who should own it, and why getting it wrong can derail an otherwise well-planned event.
This post is that explanation.
What a run-of-show is
A run-of-show (often abbreviated as ROS) is a master timing and sequencing document for a live event. It lists every single thing that happens during the event — in the order it happens, with the exact time it starts, how long it runs, who is responsible for executing it, and what depends on what.
It is not a program. A program is what the audience sees. A run-of-show is what the production team uses to actually execute the show.
It is not a script. Scripts live inside the run-of-show as references, but the ROS is a coordination tool, not a content tool.
It is not an agenda. An agenda lists sessions. A run-of-show includes every technical, logistical, and content element — including the 90-second opener video, the transition music between speakers, the AV cue to bring up house lights, the sponsor thank-you slide timing, and the moment the catering team is cleared to reset the back of the room.
A well-built run-of-show is the single document from which a complex live production can be executed by people who may have never been in that room before.
Who owns the run-of-show
This is where a lot of events go wrong: no one is explicitly in charge.
In professional event production, the run-of-show is typically owned and maintained by the show caller or stage manager — the person running the headset on show day and calling cues to the audio, video, and lighting operators. But ownership must be established clearly during pre-production. If multiple vendors are contributing elements (AV company, production company, event planner, speakers bureau), someone needs to be the single authority who consolidates inputs, resolves conflicts, and distributes the final document.
Diffuse ownership produces contradictions. The AV company’s version of the ROS says the opener video runs at 8:57. The event planner’s version says 9:00. On show morning, no one remembers which version is authoritative. Someone makes a call. The speaker who was briefed for a 9:00 start is now standing in the wings at 8:56 wondering why the audience is already watching a video.
These are not hypothetical problems.
What should be in a run-of-show
A complete run-of-show for a corporate conference contains the following elements.
Timeline and sequence
Every element of the show in order, with:
- Wall clock time — the actual clock time the element starts (not “T+15 minutes,” but “9:15 AM”)
- Duration — how long the element runs
- Cumulative offset — how many minutes into the show this element falls, so the show caller can see at a glance how far ahead or behind the show is running
The timeline should extend to before the show starts (doors open, pre-show loop, house lights state) and after it ends (outro music, audience dismissal, post-show AV teardown sequence).
Cue list
A cue is a specific technical action: a video starts, a mic goes live, lights change, a graphic is pushed to screen. Every cue in the show should be numbered and listed with:
- Cue number — so the show caller can say “stand by cue 47” and every operator knows what is about to happen
- Cue type — video, audio, lighting, graphics
- Cue description — what the cue does in plain language
- Trigger — what causes the cue to fire (show caller command, time code, or a specific line in a script)
Missing cues in a run-of-show means someone has to improvise on show day. Improvisation under pressure is how transitions get missed, wrong slides appear on screen, and open microphones pick up things they shouldn’t.
Speaker and talent information
For each segment with a speaker, the run-of-show should include:
- Full name (spelled correctly — this matters for lower-third graphics and introductions)
- Phonetic pronunciation of difficult names
- Title and company as it should appear on screen
- Mic type (lavalier, handheld, podium) and whether they need a tech check before going on stage
- Walk-on and walk-off music, if applicable
- Any special requirements (teleprompter, clicker, specific monitor configuration)
Asset list and file names
Every video file, graphic, and presentation that plays during the show should be listed with:
- The exact file name as it exists on the show computer
- File format and resolution (so the AV team can confirm it will play correctly)
- Intended playback duration
- Who approved the final version and when
This element prevents the single most common show-day crisis: a video file that was updated overnight and no one loaded the new version onto the show machine.
Dependencies and handoffs
A dependency is when one thing must happen before another can. The opener video cannot start until the house lights are down. The keynote speaker’s presentation cannot begin until the opener has fully ended and the transition music has resolved. The CEO walk-on cannot happen until the previous presenter has cleared the stage.
A run-of-show that does not map dependencies is a timeline that will collide with reality.
Owner for every element
Every row in the run-of-show should have a name or role next to it: who calls this, who executes this, who is the fallback if the primary contact is unavailable. On show day, there is no time to figure out whose job it is.
Why a bad run-of-show sinks shows
The problems that appear most often when a run-of-show is incomplete or poorly built:
Timing drift. Without accurate durations, the show falls behind by two minutes in the first segment, five minutes by the second, and by noon the catering room is being reset while the morning keynote is still wrapping. Sponsors get fewer minutes than they were promised. The closing session gets compressed. The whole day is playing catch-up.
Cue misses. A video that was supposed to start at a speaker’s line “let’s take a look” instead starts 15 seconds late because the operator did not know the cue. Or starts 15 seconds early for the same reason. In a live broadcast, a missed cue is a blooper. In a high-stakes keynote, it can break the speaker’s rhythm.
Asset confusion. A speaker submits a revised presentation the night before the event. It gets loaded on the show computer. No one updates the run-of-show. A different operator is calling the session from the original ROS and cues the old file. The speaker is presenting live and their slides are wrong.
Handoff failures. The session ends, the moderator thanks the speaker and leaves the stage, and no one is positioned to introduce the next segment because the ROS didn’t specify who was in the wings and when.
None of these problems are catastrophic in isolation. But they compound. An event where small things keep going wrong is an event where the audience stops trusting the production and starts noticing the seams. That is the opposite of what a corporate event is supposed to accomplish.
The difference between a template and a living document
A run-of-show starts as a template — a structure you fill in. It becomes a living document through the pre-production process: design reviews, speaker confirmations, tech rehearsal notes, change orders from the venue, last-minute speaker additions.
The version that matters is the final version, locked and distributed no later than 24 hours before load-in. Changes after that point should require explicit sign-off from the show caller, and all operators should be alerted. Quiet revisions to a run-of-show after lock are a known source of show-day confusion.
A note on software
Running a show out of a printed document or a spreadsheet is common and workable for smaller productions. As events grow more complex — multiple stages, broadcast components, remote speakers, large crew — dedicated show production software gives the show caller and operators a shared real-time view of the cue list with notes and status updates.
DFM’s sister product, Overture, is purpose-built for this kind of event production coordination. If you’re managing a multi-stage conference and a shared Google Sheet is starting to show its limits, it’s worth looking at.
What to ask for from your production team
If you are an executive reviewing a run-of-show for the first time, here are the questions to ask:
- Is there a named owner for every element in this document?
- Are all asset file names listed exactly as they will appear on the show computer?
- Are all dependencies mapped, and is there a plan for each one if the preceding element runs long?
- Has this been distributed to every operator who will be running a board or calling cues on show day?
- When was the last version locked, and who approved it?
A production team that can answer those questions clearly is a production team that knows what they’re doing. A team that pauses uncomfortably at any of them has some work to do before show day.
When you’re ready for a real number, our instant quote wizard gives you one in a few minutes — no sales call required.