I’ve watched a lot of event runs-of-show. Most of them are optimistic fiction. They assume the platform will hold, the internet will be stable, the speaker will click the right link, and the chat moderator won’t freeze mid-sentence. I’ve also watched those same runs-of-show disintegrate the moment something breaks—and something always breaks. The question isn’t whether your platform will hiccup. It’s whether your run-of-show has the bones to keep the event upright when it does.
This isn’t a guide to picking the perfect platform. It’s a guide to writing a run-of-show that treats platform failure as a design parameter, not an afterthought. If you’re producing virtual, hybrid, or high-stakes collaborative events, you need a document that doesn’t just list timestamps and speaker names. You need a document that anticipates the exact moment the screen goes black and tells everyone in the room—and on the stream—exactly what to do next.
Why Most Run-of-Show Documents Are Fragile
A typical run-of-show is a timeline. It tells you that at 10:02, the host welcomes attendees. At 10:05, the keynote begins. At 10:35, we transition to breakout rooms. It’s linear, tidy, and completely useless the moment the platform stutters. I’ve seen seasoned producers freeze when a livestream drops because their run-of-show didn’t include a single line about what to do if the stream drops. They had a plan for success, not a plan for reality.
The problem is that most run-of-show templates are built around the assumption of a stable technical environment. They treat the platform as a given, like gravity. But platforms are not gravity. They’re more like weather—unpredictable, occasionally hostile, and always worth a second look before you step outside. A run-of-show that doesn’t account for platform failure is a document that assumes perfect weather. And in event production, that’s negligence dressed up as optimism.
Start with the Failure Modes, Not the Agenda
Before you write a single timestamp, list every way your platform could fail during this specific event. Not generic failures—specific ones. Does your platform have a known issue with screen sharing when too many people have video on? Does the breakout room feature sometimes strand attendees in a loading loop? Have you seen the chat moderator’s panel crash when too many links get posted? Write these down. These are your failure modes, and they’re the scaffolding for a resilient run-of-show.
For each failure mode, define a trigger. A trigger is the observable symptom that tells your team the failure has occurred. For example: “Host video freezes for more than 8 seconds” or “Attendees report breakout room not loading.” Then define the response. Who speaks? On what channel? What do attendees see or hear? What’s the backup path? This isn’t a contingency plan tucked in an appendix. It’s baked into the run-of-show itself, in a parallel column or a color-coded block, so the show caller can see it without flipping pages.
Designing the Dual-Track Run-of-Show
I build my run-of-show documents with two tracks: the primary track and the degraded track. The primary track is the ideal flow—the one you hope to execute. The degraded track is what you pivot to when the platform fails in a specific way. Both tracks live in the same document, side by side, so the show caller can move between them without breaking eye contact with the stream.
For example, if your primary track says “10:05 – Keynote begins, speaker advances slides,” the degraded track might say “If screen share fails: host prompts speaker to describe slides verbally while producer troubleshoots. If video fails: switch to audio-only with static slide. If full platform outage: host moves to backup conference line and shares dial-in in chat.” Each degraded track is tied to a specific failure mode, not a generic “technical difficulties” placeholder.
This approach forces you to think about what matters in each segment. If the speaker’s slides are essential, you need a backup method to display them—maybe a PDF in a shared drive that the host can screen share independently. If the speaker’s presence is the point, you need a phone bridge. The run-of-show becomes a decision document, not just a schedule.
Assigning Roles for Failure, Not Just Success
Most run-of-show documents assign roles: host, producer, tech support, speaker wrangler. But those roles are defined for the happy path. When the platform breaks, the host often tries to fix it, the producer panics, and the speaker wrangler freezes. That’s because no one was told what their job is when things go wrong. A resilient run-of-show includes a failure role assignment for each segment.
For instance: during a panel, if the platform’s chat crashes, the host keeps the conversation moving while the producer switches to a backup chat tool (like a shared Telegram group) and the speaker wrangler monitors it for audience questions. If the video feed drops entirely, the host moves to a pre-recorded segment or a live audio-only bridge, while the producer communicates the switch to attendees via email and social media. These aren’t suggestions. They’re scripted actions, with specific language, assigned to specific people.
This also means you need to rehearse the failures. I’ve found that teams who practice platform failures are three times more likely to recover smoothly. In rehearsal, kill the internet. Mute the host. Crash the breakout rooms. Watch what happens. Then adjust the run-of-show based on what you learn. The document should evolve from rehearsal, not just be handed down like stone tablets.
Building Communication Layers into the Run-of-Show
When the platform fails, your communication channels often fail with it. If you’re relying on the platform’s internal chat to coordinate your team, and the platform goes down, you’re now blind and mute. A resilient run-of-show specifies out-of-band communication for every segment. This means a separate channel—like a dedicated Slack channel, a WhatsApp group, or even a conference call bridge—that your core team can use regardless of what the platform is doing.
Your run-of-show should list that channel at the top of every page, along with the protocol for using it. For example: “If primary platform fails, all team members switch to backup comms channel #event-backup in Slack. Producer will post status updates every 60 seconds. Do not use platform chat for internal coordination during an outage.” This seems obvious, but I’ve seen teams try to troubleshoot a crashed webinar platform by typing frantically into the crashed webinar platform’s chat. It’s like shouting into a void and expecting the void to shout back.
For attendee-facing communication, have pre-written messages ready. These should be in the run-of-show, not in someone’s head. “We’re experiencing a brief technical hiccup. Please stand by—we’ll resume in under two minutes.” Or, if it’s a hard crash: “We’ve moved to a backup stream. Please check your email for the new link.” These messages need to be approved, loaded into your email tool or social scheduler, and assigned to a specific person. The run-of-show should say: “If full outage > 3 minutes, Producer sends Backup Stream Email (see Appendix B) and posts to Twitter from @eventhandle.”
Segmenting for Isolation, Not Flow
Traditional run-of-show documents are built for flow—one segment leads seamlessly into the next. But when a platform fails, you want isolation. You want to contain the damage so one broken segment doesn’t cascade into the next. This means designing your run-of-show with hard breaks between segments, where the show caller can assess stability and decide whether to proceed as planned or switch to a degraded track.
I call these decision gates. After each major segment, insert a 60-second gate where the host engages the audience with a poll or a Q&A prompt while the producer confirms platform health. The run-of-show should explicitly state: “Gate: Producer verifies stream stability, chat functionality, and speaker readiness. If any failure, execute degraded track for next segment.” This turns a potential disaster into a controlled pivot. It also gives your team permission to pause—something most run-of-show documents treat as a sin.
This is especially critical for hybrid events, where platform failure can create a rift between in-room and virtual audiences. I’ve written about this before in Why Hybrid Events Fall Apart at the Room-to-Chat Handoff. The same principle applies: if your virtual platform crashes, the in-room experience shouldn’t just barrel forward while online attendees are left staring at a frozen screen. The run-of-show must include a gate that syncs both audiences before proceeding.
Scripting the Recovery
Most runs-of-show treat recovery as an ad-lib. That’s a mistake. When the platform fails, your host is flustered, your attendees are confused, and your team is scrambling. This is not the moment for improvisation. Script the recovery language for each failure mode, and put it directly in the run-of-show. Not in a separate crisis doc—right there, in the timeline, so the show caller can read it aloud if needed.
For example, if the screen share fails during a sponsored segment, the script might read: “It looks like we’re having a technical hiccup with the screen share. While we get that sorted, let me tell you a bit more about why we’re excited to partner with [Sponsor].” That’s not filler. That’s a bridge that keeps the sponsor happy and the audience engaged while the producer works the problem. The run-of-show should include these bridges for every segment that relies on platform-specific features.
If the failure is severe—say, the entire platform crashes—the script should direct attendees to a backup experience. That might be a simple audio conference line, a pre-recorded video, or a live social media stream. The key is that the backup is already set up and tested, and the run-of-show tells the host exactly how to redirect the audience. “We’re moving to our backup audio line. Please dial [number] and enter access code [code]. We’ll resume in three minutes.” No hemming. No hawing. Just a clear, practiced pivot.
Testing the Run-of-Show Against Reality
A run-of-show that hasn’t been tested is a wish list. I’ve seen too many teams do a single dry run where everything works, then call it a day. That’s not testing. That’s a dress rehearsal for a perfect world. Real testing means simulating the failures you identified earlier. It means running the show with the degraded track as the primary track, just to see if the team can execute it. It means timing the recovery scripts to make sure they fit within the gate windows.
During testing, pay attention to the cognitive load on your show caller. If the run-of-show is too dense, they’ll miss cues. If the degraded track instructions are buried in fine print, they’ll default to the primary track out of habit. The document should be scannable under stress. Use bold for action items, color-code the degraded track, and keep language terse. “IF: screen share freezes → HOST: read backup script (p.4) → PRODUCER: switch to backup slides.” That’s it. No paragraphs.
Also, test your backup channels. I’ve seen teams list a backup conference line in their run-of-show, only to discover during an actual outage that the line required a PIN no one had. Or that the backup stream was set to private. These are not technical failures. They’re run-of-show failures. The document should include verification steps: “Producer confirms backup line is active and PIN is shared with host 30 minutes before showtime.”
Documenting Platform-Specific Quirks
Every platform has quirks. Zoom’s breakout rooms can be slow to load if you have more than 50 participants. Hopin’s backstage area doesn’t always sync with the main stage. Microsoft Teams can struggle with external presenters who don’t have the right permissions. Your run-of-show should document these quirks and the workarounds, because on show day, your team will forget them. They’ll be focused on the content, not the platform’s personality disorder.
Create a section at the top of your run-of-show called “Platform Notes.” List the known failure points and the immediate fix for each. For example: “If breakout rooms don’t load, have host end session and manually reassign. If external speaker can’t share screen, have them send slides to producer via Slack and producer shares from host machine.” These notes save minutes of frantic googling and keep the show caller from having to make decisions under pressure.
This section should also include escalation paths. If the platform itself goes down—not just your event, but the entire service—who contacts the platform’s support? What’s the support number? What information do they need? Write it down. During a platform-wide outage, your team’s ability to get answers quickly is the difference between a five-minute delay and a cancelled event.
Building a Culture of Redundancy
Ultimately, a run-of-show that accounts for platform failure is a symptom of a larger operational philosophy: assume nothing, verify everything, and always have a spare. This means your event production team should treat the run-of-show as a living document that gets sharper with every event. After each show, do a post-mortem. What failed? What almost failed? What did we learn? Update the run-of-show template so the next event doesn’t repeat the same mistakes.
This also means investing in redundancy at the platform level. If your event is critical, don’t rely on a single platform. Have a backup streaming service, a backup conference line, and a backup communication channel. The run-of-show should list these redundancies and the triggers for switching to them. It’s not paranoia. It’s production maturity. The best events I’ve ever run were the ones where the audience never knew anything went wrong, because the run-of-show had already planned for the failure and the team executed the pivot without missing a beat.
Platform failure is not an edge case. It’s a design condition. When you build your run-of-show to account for it, you’re not just preparing for the worst—you’re giving your team the confidence to handle anything. And in live events, confidence is contagious. If your team isn’t panicking, your attendees won’t either. That’s the real measure of a successful show: not that nothing went wrong, but that no one noticed when it did.
FAQ
What’s the most common platform failure in virtual events?
Screen sharing issues top the list—frozen slides, audio-video desync, or the presenter’s screen simply not appearing. Close behind are breakout room loading failures and chat panel crashes. Most of these are recoverable if you’ve scripted a verbal bridge and have a backup method for displaying content, like a producer sharing slides from a local machine.
How do I convince stakeholders that we need to spend time planning for failure?
Frame it in terms of attendee experience and sponsor value. A single visible platform failure can erode trust and reduce future attendance. Show them data from past events where technical issues led to drop-offs. Then present the degraded-track approach as a way to protect the investment they’ve already made—not as an extra cost, but as insurance.
Should the run-of-show include a full backup platform, or just workarounds?
It depends on the event’s criticality. For high-stakes events—keynotes, paid workshops, investor presentations—a full backup platform (like a secondary stream or conference line) is worth the effort. For lower-stakes events, workarounds like audio-only fallback or pre-recorded segments may suffice. The run-of-show should clearly state which approach is in play and the trigger for switching.
How often should we update the run-of-show template?
After every event. Run a post-mortem within 48 hours while memories are fresh. Document what failed, what almost failed, and what recovery steps worked. Then update the template immediately. If you wait until the next event, you’ll forget the details and repeat the same mistakes.