What a run of show is, and is not
A run of show is a timed operating plan for the event, from the first delivery to the final departure. It is different from a general timeline, which tracks planning tasks over months. It is also different from a program, which the guests see. The run of show is for the team, and it can include details that guests should never read, such as cues, contingency plans and who to call.
Two versions are often useful: a full internal version with every cue and contact, and a shorter shared version for vendors and the client that includes only what they need to act on.
The columns that matter
A template does not need to be complicated. These columns are a useful starting point for many events, from a dinner to a conference.
- Time: the start time, and the end time or duration. Use one format throughout.
- What happens: a short action in plain words, such as "Doors open" or "Cake cutting".
- Where: the room, area or entrance, especially if the venue has several.
- Who: the person responsible, by name, plus anyone supporting them.
- Cue: what triggers the action, for example "when the DJ announces the couple".
- Notes: equipment, access, audio needs or dependencies.
- Contact: a phone number for the person responsible, so nobody hunts for it.
Start with the anchors
Begin with the fixed points that cannot move: the venue access time, the moment guests arrive, any genuinely fixed presentation or service times, and the venue's curfew. Everything else is arranged around them. Once the anchors are in, fill in the setup work before the event and the pack-down after it. Give those blocks named owners too. Loading access, room resets and rental collections can affect the schedule even when no guests are present.
Work backwards from each anchor. If the ceremony starts at four and the guests should be seated by a quarter to, the ushers need to be in position by half past three, the music needs a sound check before that and any work sharing that space must be coordinated with the sound check. Write each dependency as its own line.
A worked example
This is what a small section of the schedule might look like for a wedding reception. Adjust the times and details to your own event.
- 5:30 pm, ballroom, caterer: guests seated, first course service begins, cue is the host's welcome.
- 6:15 pm, ballroom, MC: speeches begin, with three speakers of about five minutes each, microphone tested at 5:00 pm.
- 7:00 pm, ballroom, planner: main course service begins, and the band takes a break for the meal.
- 8:15 pm, terrace, caterer and planner: dessert and cake cutting, photographer positioned first.
- 8:45 pm, ballroom, band: first dance and dance floor opens.
- 11:00 pm, main entrance, planner: last song and guest departure, with transport arriving at ten fifty.
Build in buffers and contingency notes
Build room for delays. Do not schedule every minute back-to-back. Size transition time around the actual movement, equipment reset and guest needs. Five to ten minutes might suit a simple transition; a room turnover or large group move can need much longer. Mark usable buffer so the team knows where time can be absorbed. For the moments that carry risk, such as an outdoor ceremony or a live presentation, add a plain contingency line: what triggers the backup plan, who decides and who tells the vendors.
Decide in advance who has authority to alter the schedule on the day. Without that, three people will each make sensible changes that contradict each other.
Share it, then keep it current
Send the draft to vendors early, and ask each one to confirm the lines that involve them. Their corrections can reveal unrealistic assumptions and missing dependencies. Set a date after which the schedule is locked, based on the production deadlines for this event, and after that point send updates only for real changes, always to everyone affected, with the changed lines identified.
On the day, print copies and keep a shared digital version for the team. Number your versions and mark the date on the page so that nobody works from an earlier draft.
A pre-event check
The evening before, read the whole run of show aloud once. Look for gaps: a person assigned to two places at once, a room used before it is cleared, or a cue that depends on someone who has not been told. Then check that every line has a named owner, every owner has a phone number and every vendor has confirmed their arrival time. A read-through helps find conflicts, but it does not replace vendor confirmation or a rehearsal for complex cues.
Adapting the template by event type
A wedding run of show may center on ceremony, meal and dancing, and the family and photographer groupings can take longer than anyone expects. A conference turns on rooms and transitions, so add columns for session, speaker and audiovisual needs. A gala revolves around the program of speeches and auctions, where service and production timings need to be coordinated. A private dinner may need only a dozen lines. Whatever the format, keep the same core columns so your team reads every schedule the same way.
Make each cue actionable
Distinguish a planned time from a live cue. A presenter may start at a listed time, but the audio operator still needs to know who signals readiness and what to do if the presenter is missing. Include a clear decision contact for unresolved issues. For overlapping rooms, identify the room lead and check shared staff or equipment for conflicts. Keep an accessible copy available if connectivity fails, and make sure the team knows how urgent changes will be communicated.
Where PlanWell fits
In the PlanWell Portal, you can build run-of-show items with times, locations, team assignments and internal planner notes alongside the event's tasks, vendors and guests. Choose which items are client-visible. Shared descriptions appear in the client portal; planner notes stay internal. Review visible items before sharing rather than assuming every assignment or detail is hidden. You can export the run of show as a PDF; review its contents before distributing it.