Run of Show Template for Events: A Practical Guide (+ Free Template)

A run of show is a minute-by-minute document that tells every person on your event team exactly what happens, when it happens, and who is responsible. Unlike a general event timeline, it includes AV cues, speaker transitions, contingency steps, and staff assignments - all in one living document that survives contact with the actual event day.

Most event logistics live in three or four disconnected places: a speaker schedule in one spreadsheet, AV notes in an email thread, catering timing in a text chain, and check-in logistics in someone's head. A run of show collapses all of that into a single document that every stakeholder reads before doors open.

The difference between a checklist and a run of show is scope. A checklist tracks tasks you need to complete before the event. A run of show tracks what happens during the event, second by second, with ownership clearly assigned for each action. It answers: who triggers the keynote intro music, who escorts the speaker from the green room to stage, who calls the caterer when the lunch break runs five minutes short.

Without it, that information lives in verbal agreements that evaporate under pressure.

Teams that skip it tend to discover the same problems: the AV team didn't know the keynote slides were switching from one laptop to another, catering brought the lunch setup team in during a session because nobody sent them the right time, or a speaker finished eight minutes early and nobody knew how to fill the gap. None of these are catastrophic on their own. Together, they add up to an event that felt disorganized even if the content was excellent.

A run of show is also a living document -- you update it as logistics shift in the days leading up to the event, and you print a final version for every team lead the morning of.

The core structure is a table with six columns. Everything else gets added based on your event type.

Core Run of Show Template Structure

Below is an example run of show for a half-day conference:

Conferences: Add a column for room assignments if you have breakout sessions. Include a master of ceremonies cue column so your emcee knows exact handoff lines between sessions. Flag any slot where a session could run short or long and document who makes the call to adjust.

Virtual and hybrid events: Add a live streaming cue column. Document who monitors the stream and who escalates if it drops. Include the web conferencing fallback link and who sends it to attendees if the main platform fails. For hybrid events, add a separate column for remote attendee experience -- what's happening on screen for people watching from home during in-room transitions?

Trade shows and exhibitions: Break the run of show into zones, not just time slots. Each booth or product demonstration area needs its own owner and its own sequence. Add a logistics column for load-in, load-out, and vendor arrival times.

Weddings and ceremonies: Run of show structure is nearly identical but substitute "processional cue" for "keynote intro" and add a photography column documenting which shots happen at what time. Your wedding planner and your AV or sound team need a copy the morning of.

The fastest starting point is a spreadsheet with frozen header rows, conditional formatting on the Status column, and a separate tab for your contact list and contingency protocols. Here's how to set it up:

Step 1 - Build your main table. Use the six-column structure above. Freeze row 1 so headers stay visible when you scroll. Set the Time column to HH:MM format and sort ascending.

Step 2 - Add a contact list tab. Every person named in the Owner column gets an entry: full name, mobile number, radio channel if applicable. This tab lives in the same spreadsheet so whoever is running the show can find it in one click without leaving the document.

Step 3 - Add a contingency tab. More on this below, but every critical item in your main table needs a "what if this fails" entry. The contingency tab is where those live. Reference it in the Notes column of the main table with a simple pointer: "See contingency tab: AV failure protocol."

Step 4 - Color-code by team. Use cell background color to mark which team each row belongs to -- AV, logistics, catering, speaker management. At a glance, each team lead can scan down the sheet and find their rows without reading every line.

Step 5 - Lock the final version. The day before the event, stop editing and export a PDF. Print copies for every team lead. Changes that happen the morning of get written on the printed copy -- not back in the spreadsheet, which nobody has open on the floor.

For event management teams running multiple events, platforms like Nunify's event app let you distribute the live event schedule directly to attendees and push real-time updates without reprinting anything -- which is a meaningful upgrade over a PDF the moment the schedule shifts.

Here is where most templates fail. They document what should happen. They don't document what to do when it doesn't.

A well-built run of show is as much a failure-prevention document as a schedule. Before your event, run a single-point-of-failure audit: identify every item on your run of show where one person or one piece of equipment going wrong would cascade into a visible problem for attendees. Those are your critical path items. Each one needs a documented backup.

AV failure: What is the fallback if the main projector fails? Is there a backup laptop with the presentation files? Who calls the venue's in-house AV contact and what is that number? Does the speaker have a printed copy of their slides as a worst case?

Speaker no-show or late arrival: Who makes the call to reorder sessions? What does the emcee say to hold the room? Is there a buffer session (a panel Q&A, a sponsor segment) that can be moved up?

Check-in bottleneck: If your check-in line backs up in the first 30 minutes, what is the overflow protocol? Is there a second station? Do you have a staff member dedicated to managing the queue versus processing registrations? With app-based check-in, average throughput runs 240-400 people per hour versus 40-80 per hour with manual lists -- Nunify data across 200+ events. If you are expecting 200+ attendees arriving in a compressed window, a manual list is a single point of failure. Nunify's event check-in app handles QR scanning and badge printing in one step, which eliminates the bottleneck before it starts.

Catering delay: Does your caterer know the hard time you need food ready -- not the target time, the hard time? Is there a 10-minute buffer built into your run of show before the meal is supposed to happen? If lunch is late, who tells the emcee to extend the preceding session, and by how much?

Technical support for virtual attendees: If your web conferencing platform drops, who sends the backup link and how fast? Is that link in the run of show or does someone have to find it?

Add a contingency column to your template or a separate tab with the format: Critical item | Failure scenario | Backup action | Who executes | Contact number. Fill it in at least 48 hours before the event so the decisions are made when you're calm, not when something is already broken.

Not everyone needs the full document. Here is the standard distribution:

A conference run of show has more moving parts than a single-session event, but the structure is the same. The differences are in the detail level.

Speaker management gets its own section. For each speaker: confirmed AV setup (clicker? personal laptop or house laptop?), green room assignment and pickup time, slide file received and tested (yes/no), dietary requirements for any meals they're attending, and the name of the staff member escorting them.

Session timing is enforced, not suggested. At a single-day conference, a session that runs 12 minutes long doesn't just affect the next session -- it compresses every break, disrupts catering timing, and throws off the entire afternoon. The emcee needs a hard-stop protocol in the run of show: when to give the speaker a 5-minute warning, when to intervene, and what language to use so it doesn't feel abrupt to the audience.

Breakout sessions need their own mini run of show. Each breakout room gets a separate page: room setup, AV contact for that room, session order, and who is responsible for keeping time.

Rehearsal is a line item, not an assumption. Add the technical rehearsal to the run of show itself -- the day before the event, documented with the same structure as the event-day schedule. Who is in the room, what gets tested, who signs off that everything works.

For conference-scale events, a dedicated event management platform handles the registration and agenda side, but the run of show itself should still live as a standalone document that works offline. Your operations team cannot rely on an internet connection in a hotel ballroom basement.

Vague ownership. "AV team handles transitions" is not a run of show entry. "Marcus triggers the keynote music at 8:19, confirms with Priya via radio" is. If the name of a specific human being isn't on the row, the task has no owner.

No hard stops marked. Some items on your run of show are flexible. Others cannot slip without cascading consequences. Mark hard stops explicitly -- a different color, a bold HARD STOP label, anything that makes the time constraint visible at a glance.

Distribution too late. Sending the run of show the morning of the event gives people no time to ask questions or flag problems. Distribute the near-final version at least 48 hours out. Final version goes out the evening before.

No debrief built in. Add a debrief line at the end of your run of show: 30 minutes after the event closes, all team leads gather, and you review what slipped and why. Document it while it's fresh. That information makes the next run of show better.

Building it as a static document. A run of show is a living document until the final version is printed. Assign one person to own all changes and communicate them to the team. If five people are editing, it becomes incoherent by event day.