How to create a run of show template

Use a run of show template to assign each event action a time, an owner, and a cue before distributing it to the production team. A run of show documents the sequence and timing of an event, including technical cues and departmental responsibilities, as described in TemplateArchive’s guide. Start with the copyable fields below, then add a release rule that tells the crew which version to follow and who may change it.

Key takeaways

• Give every actionable row a stable identifier, a responsible person, and an explicit trigger.
• Separate planned start times from live permission to execute a cue.
• Require affected department leads to acknowledge consequential changes before releasing a new version.
• Test the template against an overrun and a missing dependency before adopting it across events.

Choose the document your team needs

An attendee program lists the public sequence, while a run of show adds the backstage actions required from individual departments, according to TemplateArchive. Keep those two purposes separate when selecting a starting document. Decide who needs to act from each version before deciding how it should look.

If you searched for an “events programme template,” Canva offers editable and printable event program designs. Use that route for the guest-facing artifact. For production, choose a document with room for responsibility and technical instructions.

If your team uses “show map,” define the term in the document header. Use it here to mean the overview of the event’s sequence, rooms, and major handoffs. Connect that overview to detailed cue rows through shared identifiers so a room lead can move from the overview to the relevant instructions.

Select a starting format

Georgia Tech’s planning resources include both a run of show document and a separate AV run of show spreadsheet. Choose a general document for reviewing the event sequence, or an AV-oriented starting point when the immediate task is technical coordination. Inspect the actual fields before adopting either.

MobileUp provides its template in Excel, PDF, and Google Sheet formats. Choose an editable working format and designate a released copy for offline use. Make the version label visible in both.

Rundown Studio lists corporate, conference, and broadcast templates with different production fields. Start with the format closest to your operating task, then remove fields that nobody will use. Apply the same selection test to anything labeled a “run of the show template.”

Copy these run of show template fields

Build the working file in your existing spreadsheet or document tool. Use the following structure as a specification, with one record per actionable item. Keep supporting files behind references so the instructions remain readable during a rehearsal.

Document header

Copy these labels above the event sequence and complete them before issuing the first review version:

• Event and scope: event name, date, venue, rooms, and covered operating period.
• Time convention: time zone, clock format, and treatment of elapsed time.
• Release identity: version, release timestamp, document owner, and approval status.
• Decision authority: show caller or schedule authority, deputy, and escalation route.
• Distribution: working-file location, released-copy location, and offline fallback.

Repeating action record

Create these fields for every action. Use separate columns if that makes the document easier for your team to scan:

• Item ID: a permanent reference, such as GS-020.
• Planned timing: start, duration, and calculated end.
• Location: room, stage, holding area, or operating position.
• Action: a specific instruction describing what happens.
• Responsible person: the named owner and department.
• Trigger: the clock time, spoken cue, or confirmed condition that permits action.
• Prerequisites: required readiness, preceding item IDs, or asset versions.
• Department instructions: the exact audio, video, lighting, or floor action required.
• Exception response: the hold condition, approved alternative, and decision contact.
• Change status: proposed or released, with affected-owner acknowledgment where required.

TemplateArchive describes item numbers as identifiers for production cues, alongside timing and department columns in its run-of-show guidance. Our recommendation is to keep those identifiers unchanged when inserting or moving rows. Assign a new ID to a new action and preserve the existing references.

Put phone numbers and communication channels in a controlled contact list referenced from the header. Decide who should receive that list separately from who should receive the event sequence. Keep personal contact details out of guest-facing exports.

Build and release the document step by step

Set the anchors and work backward

PlanWell recommends starting with fixed points such as venue access, guest arrival, fixed presentation times, and curfew, then working backward through dependencies. Mark each anchor as fixed or negotiable and record who can authorize a change. Ask the responsible lead to confirm the basis for each fixed designation.

Work backward from each anchor until the preparation is assigned. For a presentation start, write separate rows for playback verification and presenter readiness if different people own those actions. Give each row an observable completion condition, such as “approved deck loaded and opening slide checked.”

Separate a planned time from a live cue

PlanWell distinguishes a planned start time from the live signal an operator needs to act. Put both in the record. For example, enter a planned start of 9:00 a.m. and a trigger of “show caller gives opening cue after stage-ready confirmation.”

Assign an owner to every readiness confirmation. Require the stage manager to report presenter readiness and the playback operator to report asset readiness, if those are the agreed roles. Leave the final go decision with the named caller.

Walk the handoffs with department leads

MobileUp recommends reviewing the document with stakeholders and conducting a walkthrough or dry run to test timing and flow in its creation guide. During that review, ask each lead to verify the rows they execute and the prerequisites they supply. Record unresolved questions beside the affected rows.

For virtual segments, Princeton recommends a shared team document and assigned support for tasks such as chat moderation and compiling questions. Add those responsibilities explicitly when they are in scope. Name the person who decides which questions reach the host.

Establish the release boundary

PlanWell recommends a schedule lock, identified changes after that point, and versioned copies in its distribution guidance. Extend that approach with an acknowledgment rule for changes affecting execution. Keep a proposed change pending until the responsible leads confirm their revised instructions.

Use AI for Event Planning: From Static Plan to Controlled Change as a companion resource when reviewing the wider planning process. For this document, write the release rule directly into the header. Include the route for urgent changes when the working file is unavailable.

Work through a general-session opening

Use the following generic pattern to test your template. Set a general-session opening for 9:00 a.m., followed by a video and a keynote, with a fixed handoff to the next program block at 9:30 a.m. Treat these as practice values to replace with approved event details.

Write the opening sequence

Create GS-010 for presenter readiness at 8:55 a.m., owned by the stage manager. Set its completion condition to “presenter in position and microphone check complete.” Create GS-020 for playback readiness, owned by the video operator, with the approved file version recorded.

Create GS-030 for the 9:00 a.m. opening. Assign the show caller authority to release it after GS-010 and GS-020 are confirmed. Give the host’s introduction its own duration, then reference the video cue and keynote introduction through separate IDs.

Add an approved alternate path

For the video cue, write a hold condition covering unavailable playback. Ask the program authority to approve a host bridge as an alternate, including the wording and the cue for entering the keynote. Record the point at which the caller must choose between waiting and using that alternate.

Keep the alternate alongside the affected cue and mark its approval status. Ask the host and relevant operators to rehearse the branch. Require confirmation that the fallback wording matches the next action.

Test an overrun

Move the keynote start later in the practice copy while preserving the 9:30 a.m. anchor. Require the team to identify an approved duration adjustment and the person authorized to accept it. Keep any unapproved cut marked as a proposal.

Record the resulting change against the affected item IDs. Ask the stage manager and caller to acknowledge the new instructions before marking the version released. Use this exercise as the acceptance test for your template’s change-control fields.

Decide how much detail to keep under live control

Set a boundary between live execution instructions and supporting production detail. Put the action and its trigger in the cue row. Reference the longer asset specification or preparation checklist where the operator needs additional detail.

Approve added fields according to a practical rule: retain a field when a named role uses it to execute, approve, or recover an action. Ask the field’s sponsor to identify that role. Move background information into supporting documents when it has no live operating purpose.

Assign ownership of the document itself

Use a small owner map for the release process:

• The document owner maintains the working sequence and prepares releases.
• Department leads confirm instructions and dependencies within their responsibility.
• The program authority approves changes to content or program commitments.
• The show caller controls live cues within the agreed authority boundary.

Allow one person to hold more than one role if that fits the production. State the combined responsibility explicitly and name a deputy for decisions that must remain available during the show. Test the escalation route during rehearsal.

Require acknowledgment before treating a change as released

A newly edited start time should remain proposed until the affected owners confirm it. Require acknowledgment when a change alters an owner, a location, or a prerequisite, even if the visible start time stays the same. Record who accepted the change and which version contains it.

This is our recommended extension to version control. Pair each material change with a short delta record containing the affected IDs, the revised instruction, the approver, and acknowledgment status. Rehearse an urgent verbal update followed by a written record.

If AI is proposed for drafting or checking the run of show, define its permitted actions separately from release authority. Require source references for suggested edits and keep consequential changes approval-gated. Event Compsia’s operating standard requires system-specific acceptance tests and manual fallback, as reflected in its production trust and claims boundary.

Frequently asked questions

What is a run of show template?

A run of show template is a reusable structure for recording an event’s sequence, timing, and production instructions, consistent with TemplateArchive’s explanation. Use it to assign responsibility and connect actions to their cues. Add a visible release identity before distributing it for execution.

How do you create a run of show document?

Start with fixed event anchors and work backward through preparation and dependencies, following the approach described by PlanWell. Assign each action an owner and a trigger. Review the sequence with department leads, test exception paths, and issue an approved version.

What should a run of show include?

PlanWell’s starting fields include timing, action, location, responsibility, cues, notes, and contact information in its template guide. Add stable IDs and release status to support controlled changes. For consequential cues, specify prerequisites and the person authorized to choose an alternate.

What are some good run-of-show templates for events?

Choose by the operating detail your team needs. Before adoption, test the candidate against a delayed start and an unavailable asset.

Choose the next release to test

Take one upcoming event document and assign an owner to test its opening sequence. Ask that person to demonstrate how a late change becomes approved, reaches affected operators, and remains available offline. Agree on the acceptance criteria before adding more fields.

If you are evaluating AI support for that process, map an event-company production perimeter around one bounded operation. Name the release owner and the permitted actions before authorizing a build.