A webinar run of show is the production team’s working schedule: it records what happens, when it happens, who owns it and what cues or fallback steps are needed. Use the free template below as a starting point, then adapt its segments to your session rather than treating the example timings as a standard.
It differs from the short agenda attendees see. The agenda tells them what the session covers; the run of show tells the host, moderator and technical operator how to deliver it, including the backstage actions that should not appear on a public agenda.
What a webinar run of show is for
Think of the run of show as a shared instruction sheet for the people delivering the event. At 10:05, for example, it might tell the host to introduce the speaker, the moderator to post a resource link in chat, and the operator to switch from the holding slide to the presentation. A simple agenda might only say “Welcome and introductions”.
That distinction matters even for a small webinar. If one person is hosting and operating the platform, the document still helps separate speaking from clicking, and makes it easier to spot what can be simplified. With a larger team, it prevents assumptions such as “someone will launch the poll” or “the speaker knows when to stop”.
A run of show is not a guarantee that the event will run perfectly. It is an event-specific planning aid: it gives the team a common sequence, makes ownership visible and provides a place to record what to do if a key step fails. The U.S. Forest Service webinar run-through checklist recommends reviewing flow and timing, checking the technical setup and agreeing how the moderator will manage overruns.
The template is useful for a product demonstration, a devotional session, a training webinar or a local business presentation. If you already work with recorded teaching material, the guide to an always-on stream of recorded language classes offers a different planning problem: keeping a repeatable broadcast running rather than coordinating one live event.
Template: event details and contacts
Start with the information the team will need to find quickly. Put it at the top of the document, before the timed rows. Avoid relying on a calendar invitation for details that matter during the session: an operator may be working from the run of show, while a moderator has the invitation open.
| Field | What to record |
|---|---|
| Event name | The name used in the invitation and on the opening slide |
| Date and time | Local date, start and hard-stop time, plus the time zone |
| Attendee-facing agenda | The short list of topics and any published timings |
| Platform and access | Event link, host access method and any backup contact route |
| Host and speakers | Name, role, contact method and segment they lead |
| Moderator | Who watches questions, manages chat and signals the host |
| Operator | Who controls slides, media, recording and platform actions |
| Backstage channel | Where the team can message without distracting attendees |
| Decision-maker | Who can approve a change to the sequence or ending time |
Use role names as well as personal names where useful. “Operator: Rina” is more actionable than “Rina”, especially if a substitute has to step in. If one person holds several roles, write them explicitly and check that the actions do not collide. A host cannot reliably deliver a detailed explanation while also launching a poll at the same moment.
Note the intended outcome in one sentence. For example: “Attendees should understand the registration process and know where to ask for help.” This helps the team decide whether a late question belongs in the session, whether a demo can be shortened, or which point must be preserved if time is lost.
Add a link or location for the working materials: slides, demo account, handout, speaker notes and any approved recording. If a file needs to be downloaded or opened before the event, make that a named pre-event action rather than a memory test during the live session.
Template: timed programme segments
Set the fixed start and end times first, then make one row for each meaningful change in the programme. Include a start time, duration, segment, owner, cue or action, and technical needs. A separate “backup” column is helpful when a failure would interrupt the session.
Here is a filled illustrative sequence for a 60-minute webinar. It is one possible arrangement, not a recommended universal schedule. Change the holding period, presentation, demo and question time to fit the format, audience and hard stop.
| Start | Duration | Segment | Owner | Cue or action | Technical need or fallback |
|---|---|---|---|---|---|
| 00:00 | 5 min | Waiting room and holding slide | Operator | Admit attendees or open the room; display welcome and housekeeping | Confirm slide is visible; host joins backstage |
| 00:05 | 3 min | Welcome and agenda | Host | Begin when operator gives the ready cue; state the session plan | If speaker is not ready, moderator posts a brief holding note |
| 00:08 | 2 min | Introductions | Host | Introduce speaker and explain how to submit questions | Check speaker audio before handing over |
| 00:10 | 25 min | Main presentation | Speaker | Operator advances slides on speaker cue, if required | If slides fail, speaker continues from notes or shares a backup PDF |
| 00:35 | 10 min | Live demonstration | Speaker and operator | Operator shares the prepared demo view | If live demo fails, play a prepared recording or explain the steps verbally |
| 00:45 | 10 min | Questions and answers | Moderator and host | Moderator selects questions; host answers and watches time | Group duplicates; reserve a route for unanswered questions |
| 00:55 | 5 min | Closing | Host | Summarise key point, state next step, thank attendees | Operator leaves closing slide visible while attendees exit |
The rows total the planned hour, but that does not mean each segment should be protected equally. If the session’s purpose is audience questions, allocate that time deliberately; if it is a short lesson, a long opening may be unnecessary. Decide in advance which segment can be shortened and which content must remain. Write that rule in the document, not just in the organiser’s head.
A row should describe an action the team can recognise. “Demo” is a label, not an instruction. “At the host’s ‘show the form’ cue, operator shares the prepared browser tab” gives both people a point of coordination. The Vimeo guidance on webinar run of show also describes this kind of document as more operational than an agenda; treat vendor-authored guidance as practical advice, not as an industry rule.
Add owners, cues and backstage actions
Give every segment one clearly accountable owner, even where several people contribute. “Host and moderator” can be appropriate for shared delivery, but note who does what: the moderator gathers and sorts questions; the host answers them. When ownership is ambiguous, a basic action can be missed because each person expects the other to do it.
A cue is the signal that a person should begin an action. It may be a spoken phrase (“I’ll hand over to you now”), a time on the schedule, a private message, or a visual signal agreed in rehearsal. Record the cue in plain language. If the operator is waiting for a phrase, use the phrase; do not write only “switch slide”.
Backstage actions include opening a poll, pinning a link, muting a noisy line, advancing slides, admitting late attendees or checking whether a speaker is ready. Keep those actions in the production document even when they are invisible to the audience. If the action changes what viewers see or hear, specify who performs it and the cue that triggers it.
For each hand-off, note both ends. For example: “Speaker finishes summary; moderator posts Q&A prompt; host takes first question.” The transition can be smooth in speech but still fail operationally if nobody is assigned to post the prompt. Rehearsing these joins is often more useful than reading every slide aloud.
Use a single backstage communication method and record it near the contact details. If the team is using a separate chat, decide whether urgent messages should be sent there or spoken privately through the event platform. Avoid creating several channels with no clear priority; the host should know where to look for a “pause” or “skip this segment” signal.
Include interaction and transitions
Questions, polls and chat need their own rows or explicit actions within a segment. Decide who watches responses, who chooses which questions to surface, and how the host will know when a poll is ready. If the moderator is screening questions, agree whether they will group duplicates, set aside off-topic submissions or prioritise questions related to the session’s goal.
Write a transition into and out of each interaction. For a poll, that might be: host explains the question; operator launches it; moderator watches for responses; operator closes it; host comments on the result. If the platform’s poll function is unavailable, the fallback could be a simple chat response, provided the team has checked that approach beforehand.
For a live demo, clarify what the audience should learn and which screen or file should be visible. Close notifications, prepare the correct tab and decide whether the operator or speaker controls screen sharing. If you use a recorded demonstration as a fallback, check that it contains the relevant steps and that someone can start it without searching through folders.
Transitions matter in non-demo formats too. A devotional webinar might move from an opening welcome to a reading, then to a speaker, then to questions. A local business session might move from a customer problem to a short walkthrough and then to next steps. The names differ, but each hand-off still needs a clear end cue, next owner and any asset change.
If the event is part of a broader video workflow, keep the distinction clear: this template is for one scheduled session. A guide to mixing lofi tracks for a continuous YouTube radio stream deals with preparing material for ongoing playback, not with moderating a live webinar’s questions and speaker hand-offs.
Add fallback steps for likely issues
Do not try to predict every possible problem. Identify the failures that would stop the next segment, then write a short response that a colleague can execute. “Troubleshoot audio” is too broad. “If the speaker’s audio drops, moderator sends the private reconnect message; host fills the gap with the session summary; operator keeps the holding slide up” gives the team a first move.
| Likely issue | First action | Who owns it | Keep the event moving by |
|---|---|---|---|
| Speaker cannot join | Contact speaker using the listed backup route | Producer or host | Start with housekeeping or the host’s opening |
| Speaker audio drops | Send the agreed private message and check whether they can rejoin | Moderator | Pause the segment or move to questions already collected |
| Slides do not appear | Stop advancing and switch to the prepared backup file | Operator | Ask speaker to continue from notes while the file is restored |
| Live demo fails | Stop waiting for the page or account to load | Operator and speaker | Play the checked recording or explain the process verbally |
| Timing runs over | Signal the host at the agreed checkpoint | Moderator | Shorten the flexible segment; preserve the stated hard stop |
| Poll or chat action fails | Tell the host privately and use the agreed alternative | Moderator | Ask for a verbal response or move on |
Fallbacks should fit the actual platform and team. A recording is only useful if the person who needs it can locate and play it; a second speaker is not a realistic backup unless they have the material and access. Keep alternatives modest enough to practise. The Forest Service checklist is a useful prompt to review technical setup and agree how to manage overruns before the event.
Set an overrun rule that reflects the session’s purpose. For example, the moderator might privately warn the host when the presentation reaches its planned end, and the host might cut a non-essential example rather than remove the promised question period. Another event may need to preserve a demonstration and take fewer questions. There is no single right allocation; communicate the decision to the team and, if needed, tell attendees how unanswered questions will be handled.
Adapt and share the template with the team
Copy the table into a shared document or spreadsheet and remove fields your event does not need. Keep the event facts at the top and the timed sequence in one place. If the team uses a different tool, preserve the same practical information: timing, owner, cue, technical action and fallback. A format is useful when the people delivering the event can find and update it quickly.
Before the event, check the date, time zone, platform access, audio and video, slides, demo files and backstage channel. Read through the schedule with the host, moderator and operator. Practise the transitions that involve a screen change, speaker hand-off, poll or fallback. This need not become an elaborate production process; it should be enough to uncover unclear cues while the team can still fix them.
Share one current version with everyone and make the last-change owner clear. If a speaker changes a slide or the event start time shifts, update the shared copy and notify the people whose actions change. A run of show with two conflicting versions can create more uncertainty than no document. Keep a simple note of what changed after rehearsal and what needs confirmation before going live.
After the session, note where the real timing differed, which cues were missed and whether a fallback was used. Update the template for the next event only where the observation is relevant; one unusual technical problem does not automatically mean every future webinar needs the same contingency. If you also operate a persistent channel, the comparison of a spare PC and cloud streaming in India can help frame a separate equipment decision, but it is not a substitute for planning this event’s roles and timing.
For a team whose recurring pain is keeping a prerecorded YouTube broadcast running while the local computer is off, StreamNeo turns an uploaded video into a YouTube live stream that can be monitored and restarted if it drops, so the organiser does not have to keep that machine on overnight. That is a different job from the live speaker cues in this template, and it is YouTube-only.
Before committing, compare the operating options on the pricing page. When the file and channel are ready, start free — 24-hour trial, no card.
FAQ
What is a webinar run of show?
It is the delivery team’s operational schedule for a webinar. It adds timing, owners, cues, technical actions and contingencies to the short agenda attendees receive.
What belongs in a webinar run of show?
Include event details and contacts, one row per segment, timing, the owner, the cue or action, and any technical needs. Add a fallback for steps that could interrupt the programme, plus the team’s overrun and backstage communication plan.
How is a run of show different from an agenda?
An agenda is a concise attendee-facing outline of topics and approximate order. A run of show is more detailed and internal: it tells the delivery team who does what and how the programme moves from one segment to the next.
Should every webinar use the same timings?
No. Use the example only as a starting point and fit the schedule to the event’s purpose, audience and hard stop. Decide which content is flexible, rehearse the hand-offs and make the overrun plan clear to the team.