Run and Show: How to Build a Run of Show

If you searched “run and show” to organize an event, start by building a run of show with a named owner for each cue. A run of show records the event’s sequence and timing, with activities and responsibilities attached, as described in EventX’s planning guide. Use the template below to specify who acts, what must be ready, and who can approve a change.

Key takeaways

• Give each executable cue one accountable owner and a specific readiness condition.
• Keep planned times, actual times, and approved recovery decisions in separate fields.
• Connect cue locations to a versioned show map using consistent location names.
• Release schedule changes through a named approver and require acknowledgment from affected leads.
• Test a failed cue and the manual fallback before approving any AI-assisted production path.

Separate the agenda, run of show, and show map

For your planning documents, make an explicit distinction between the attendee agenda and the operational run of show. Put session titles and attendee-facing start times in the agenda. Put the execution detail in the run of show, including the instruction that authorizes the next action.

That operational scope follows EventX’s description of a run of show, which includes timing, activities, roles, and responsibilities. For this guide, use “agenda” for the participant-facing program and “run of show” for the working production document. Adopt those labels across the project so reviewers know which document they are approving.

Treat the show map as a separate spatial reference. Label the stage entrances, holding positions, control location, and other relevant operational areas. Use exactly the same labels in the run of show, and put a version identifier on both artifacts.

For example, write “speaker ready at holding position H1” in a cue record. Put H1 on the show map and confirm the route during rehearsal. Avoid leaving a crew member to interpret “backstage” when the instruction depends on a particular entrance.

Set a boundary around the document’s detail. Include an item when someone needs its timing or completion state to perform another action. Keep unrelated planning tasks in the project plan, with a reference where their completion becomes a show-day dependency.

A copyable run of show template

Build your run of show template around executable records. Handbid recommends recording start and stop times, allowing for overruns, and reviewing the plan with the team. Add the following fields to make those reviews specific enough to approve or reject a cue.

• Cue ID and location: Give the action a stable identifier and a location label that matches the approved show map.
• Timing: Record planned start, planned duration, and any fixed deadline. Keep actual start and finish separate.
• Action: Write the instruction in operational language, such as “start opening video after the caller’s go.”
• Readiness condition: State what must be confirmed before execution, such as the speaker being in position.
• Execution owner: Name the role responsible for carrying out the action and the channel used for confirmation.
• Decision authority: Name the role authorized to release the cue or approve a departure from the plan.
• Fallback: State the approved alternative and the condition that activates it.
• Release evidence: Record the document version, relevant asset version, approval state, and affected leads’ acknowledgments.

Use one record for each action that needs an independent readiness check or release instruction. Separate “play video” from “bring speaker onstage” if each requires its own confirmation. Keep them together only when the same owner can execute the complete instruction under one release.

Whether you call the file a run of show template or a run of the show template, keep the field definitions identical. Put a short instruction above the records explaining how to distinguish a proposed change from an approved instruction. Require unresolved fields to say “unconfirmed,” with an owner responsible for resolving them.

Before adopting the template, ask a department lead to read one cue aloud and explain the next action. Revise any field that requires an explanation outside the record. Use that reading test again after a substantial change.

Build and release the document in five steps

1. Establish the hard boundaries

Start with the venue access and departure requirements. Handbid recommends using the rental agreement’s access and exit times as the boundaries of the timeline. Record the exact obligation and its source before filling in the program.

Within those boundaries, identify which times require explicit approval to move. Distinguish a planned session start from a contractual departure deadline. Assign someone to resolve any uncertainty about which constraint takes priority.

2. Write the handoffs

For each segment, specify the condition that allows the next segment to begin. Replace a vague instruction such as “speaker transition” with an observable handoff, such as “stage manager confirms speaker at H1.” Give the receiving role a way to acknowledge readiness.

Check participant movement alongside crew activity. Handbid’s rehearsal guidance asks teams to verify whether guests can move between event elements and whether staff can complete overlapping responsibilities. Use the same test for each transition in your program.

3. Assign execution and approval separately

Name the person or role that performs each action, then name the authority that can release it. Allow one person to hold both responsibilities when the production plan supports that choice. Record a backup for any decision role whose absence would leave the next action unresolved.

For this method, give the show caller authority over live cue release and give the producer authority over material program changes. Agree on the boundary before rehearsal. Write down which changes require additional approval, including changes to protected program content.

4. Rehearse the exceptions

Review the plan with the operating team, consistent with Handbid’s recommendation to run through the timeline together. Test one transition with a missing readiness confirmation. Test another with an unavailable asset.

Require the team to identify who makes the decision and which fallback becomes active. If the answer depends on finding an unnamed approver, revise the owner record. Keep the exception open until someone accepts responsibility for resolving it.

5. Publish an identifiable release

Give the approved document a release identifier and a named publisher. Require affected department leads to acknowledge a changed instruction before marking distribution complete. Retain a usable fallback copy and specify how the team will identify the active release if the shared document becomes unavailable.

For the broader planning discipline behind these changes, use our guide to AI for event planning and controlled change. Apply the release rule to the whole instruction, including its referenced map and media asset.

Worked pattern: an opening video followed by a speaker

Use a general-session opening to test the template. Set a planned opening at 9:00 a.m., followed by a video and a speaker entrance. Treat these times as rehearsal inputs, with approval still required for the final production schedule.

Create cue OPEN-01 for the video. Assign playback execution to the playback operator and release authority to the show caller. Require confirmation that the approved file is loaded, with its identifier recorded in the cue.

Create cue OPEN-02 for the speaker entrance. Assign the stage manager responsibility for confirming the speaker at H1, with H1 marked on the show map. Require the caller to receive that confirmation before releasing the entrance.

Write a fallback for an unavailable video before rehearsal. One option to approve is a direct host introduction followed by the speaker entrance. Have the producer approve the alternate wording, and give the caller explicit authority to select that path when the video readiness check fails.

During the test, withhold the playback confirmation. Ask the caller to select the approved path and record the decision against OPEN-01. Keep the original planned time visible and enter the actual sequence separately.

Use the resulting record to review the instruction. Check whether the fallback had an owner, whether the alternate wording was available, and whether the speaker entrance still had a valid readiness condition. Approve the sequence only after those questions have definite answers.

Decide who can change the plan, and where AI fits

Use a recovery rule that distinguishes flexible content from protected boundaries. Before the show, mark which segments may be shortened, the minimum version approved for each, and the role authorized to make the cut. Keep a separate list of times or obligations that require escalation.

If the program runs late during rehearsal, require a specific recovery proposal. Record the segment to be shortened, the proposed new duration, and the approving role. Preserve the original schedule so the record shows both the plan and the decision made during execution.

Apply the same discipline to document distribution. Separate approval, publication, and acknowledgment in the release record. Under this method, a change remains pending until the authorized role approves it, the publisher releases it, and the affected leads acknowledge receipt.

For AI assistance, start with a bounded candidate task such as checking cue records for missing owners or comparing a proposed revision with the active release. Treat these as proposed uses to test. Require every flagged issue to point back to the relevant record, and leave live cue release with the assigned human authority.

Compsia designs, deploys, and operates custom AI production systems with system-specific data, actions, owners, controls, acceptance tests, and operating limits, as described in our production trust and claims boundary. For a run-of-show-related system, define permitted actions and manual fallback before approving any production path. Test stale versions, unavailable inputs, and partial distribution failures within that exact scope.

Choose a document-only process when the unresolved problem is ownership or approval discipline. Evaluate a managed system when you can define recurring work, authorized inputs, acceptance tests, and an accountable operating owner. Require that definition before selecting an AI tool.

Frequently asked questions

What is the meaning of run the show?

The expression “run the show” means to lead or be in charge, according to YourDictionary. In your production plan, translate that broad responsibility into named authority for program changes and live cue release.

How do you make a run of show?

Start with venue access and exit limits, then arrange the event activities chronologically, following Handbid’s planning approach. Add an execution owner, readiness condition, and fallback to each actionable cue. Rehearse the handoffs and publish an identifiable approved release.

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

Use the agenda to communicate the participant-facing program. Use the run of show for operational instructions, consistent with EventX’s inclusion of timing, activities, roles, and responsibilities. Keep cue release authority and fallback instructions in the production document.

What are the reviews like for the TV show Run?

The supplied Rotten Tomatoes listing for Run’s first season shows an 81% critics score and a 46% audience score. Its critics consensus praises the performances while noting uneven pacing.

Choose one transition to approve

Take the transition with the most unresolved dependencies in your next production. Assign its execution owner and release authority, then test the fallback with the operating team. Decide whether the remaining work is a document correction or a recurring operation worth building into a managed system.

If you choose the system path, map an event-company production perimeter around that operation. Bring the cue record, approved inputs, and failed-rehearsal notes so the next decision has a defined scope.