Guide · Video & communication
A Webinar Run of Show That Helps the Host
Prepare a usable event plan with owners, transitions, demo recovery, and a clear route for audience questions.
A webinar agenda tells the audience what to expect. A run of show tells the people running it what to do. Keep those documents related, but give the host and producer the operational details they'll need when a demo takes longer than planned or a guest loses audio.
Write the promise at the top
Describe what a viewer should understand or be able to do by the end. For a hypothetical CRM workshop, that might be choosing which data to move and checking a small test import. Use that promise to decide what belongs in the session.
A long feature tour may be tempting, but it can consume the time needed for the worked example. Mark which segments are essential and which can be shortened. That gives the producer a sensible decision when the clock slips, instead of forcing them to guess what the host considers important.
Give every transition an owner
List the segments in order, with an approximate duration, who leads, what is on screen, and what needs to happen next. Include the opening screen, introductions, demo handoff, questions, and closing instructions. Small transitions are easy to forget because they feel obvious during rehearsal.
If a guest is presenting, agree on how they'll know it's their turn. Decide who watches the questions and how those questions reach the host. A chat feed can be useful, but reading every message while demonstrating software is a demanding second job.
Rehearse the demo you intend to show
Use the actual account, sample data, and screen arrangement planned for the event. Walk through the part that depends on a file, login, device permission, or outside service. Confirm that the audience can read the relevant text at the size it will be shared.
Prepare a recovery option for the most important teaching point. That might be a saved screenshot of the expected result or a previously recorded walkthrough. Label a recording as a recording. A fallback should preserve the lesson without making the audience think a prerecorded action happened live.
Leave room for questions and overruns
Build a small buffer around the uncertain parts. A useful audience question can be worth answering, but the host needs a way to keep it from consuming the whole session. Agree on which questions can be answered immediately and which should go into a later discussion.
For example, a question about why a field was mapped a certain way may help everyone understand the demo. Troubleshooting one attendee's installation may be better handled separately. The distinction should follow the session's promise, not whether the question is interesting to the presenter.
Write down the final handoff
The event doesn't end cleanly if viewers leave unsure where the replay, resources, or next step will appear. Put the exact closing instructions in the run of show and confirm them before going live. Don't promise a delivery process nobody has arranged.
Afterward, record what actually happened. Note the segment that ran long, the question that exposed missing context, and any demo problem worth fixing. Those notes are more useful for the next event than a plan that still pretends everything followed the original timing.