Tutorials Enterprise

Producing a Corporate Town Hall or Live Event

Intermediate · ~20 min

Overview

A corporate town hall has a smaller audience than a broadcast and a comparable intolerance for failure, because the audience is the entire company and the presenter is the chief executive. The production problems are rarely creative: they are redundancy, remote presenters, and the fact that nobody rehearsed. This guide covers the failure modes specific to internal live events and the preparation that eliminates most of them.

What You Need

A clear owner for the event on the production side, and one on the business side
Redundant internet, ideally on different providers
A rehearsal with the actual presenters, not a technical test alone
A moderated question mechanism, decided in advance
Captioning, since internal events have accessibility obligations too
A recording, because most internal events are watched afterwards

Steps

Rehearse with the actual presenters

A technical test proves the system works. A rehearsal with the real presenters finds that the chief executive stands outside the shot, that the slides are the wrong aspect ratio, and that nobody agreed who introduces whom. Most town hall failures are human and procedural rather than technical, and only a real rehearsal surfaces them.

Build redundancy where failure is most likely

Two internet connections on different providers, a backup recording running locally, a second microphone on the main presenter, and a plan for continuing if the streaming platform fails. Redundancy in the right places is inexpensive. Discovering you had none is not.

Treat remote presenters as the main risk

A remote executive on domestic wifi is the most likely point of failure and the least controllable. Get them wired rather than wireless, have them join early to test, brief them on framing and lighting in advance, and have a fallback (a dial-in audio path, or a pre-recorded segment) ready if their connection degrades.

Decide how questions are handled before the event

Live unmoderated questions from an entire company is a decision, not a default. Decide whether questions are pre-submitted, moderated live, or open, who filters them, and who reads them out. Deciding during the event produces awkward silences or questions nobody wanted broadcast internally.

Caption it, and record it properly

Internal events carry the same accessibility considerations as external ones, and a substantial share of the audience will watch the recording later rather than attending live. Provide live captions, and produce a properly captioned recording afterwards rather than posting the raw stream.

Have someone watching the audience experience

Assign a person whose only job is watching the stream as an ordinary viewer would, on a normal machine, and reporting problems. Control room monitors do not tell you that the stream is buffering for viewers or that the captions are not appearing. This role catches problems nobody in the production sees.

Pro Tips

Rehearse with the real presenters. Technical tests do not find the human problems.
Wire remote presenters. Domestic wifi is the single most common point of failure.
Record locally as well as streaming. It is free insurance and the recording is usually watched more than the live event.
Assign someone to watch as an ordinary viewer. Control room monitors hide the audience experience.
Agree the question process in advance, including who decides what gets asked.

Knowledge Base

What You'll Learn

Internal live events fail in predictable, mostly non-technical ways. Below: why the audience is less forgiving than you would expect, and where redundancy actually pays.

Why an Internal Audience Is Less Forgiving

It is tempting to treat an internal event as lower stakes than a public one. In practice the tolerance is often lower, for reasons worth understanding.

The audience is captive and simultaneous. Everyone is watching at the same time, frequently because they were told to, and a failure interrupts the entire organisation at once. A public stream failing loses some viewers. An internal one failing generates several hundred messages within a minute.

The presenter is senior. A technical failure during the chief executive's address is visible to exactly the people who decide production budgets, and it is remembered.

Content is frequently sensitive. Restructures, results, and strategy announcements have a specific timing, and a failure that delays or truncates the message has consequences beyond inconvenience.

Expectations are set by consumer platforms. An audience that watches professionally produced streaming daily judges an internal event against that, not against what the budget would suggest.

None of this argues for a bigger budget. It argues for spending the available budget on reliability rather than on production value, which is the opposite of the usual instinct.

Where Redundancy Actually Pays

Redundancy has a cost, and applying it everywhere is neither affordable nor necessary. It pays in specific places.

Connectivity is the highest-value redundancy, because it is the most likely thing to fail and the failure is total. Two connections on different providers, with the encoder able to use either, addresses the single biggest risk.

The main presenter's audio is second. A failed microphone on the person everyone came to hear ends the event. A second microphone already open costs almost nothing.

Local recording is third and nearly free. If the stream fails entirely, you still have the content and can distribute it afterwards, which converts a disaster into an inconvenience.

Remote presenter fallback is fourth: a dial-in audio path or a pre-recorded segment ready to play if a connection degrades.

What rarely justifies redundancy at this scale is cameras, switchers, and graphics. Those fail less often and degrade gracefully. An event can continue on one camera. Spending the reliability budget on connectivity and audio rather than on a second switcher is the correct allocation.

Where This Fits

This guide covers one specific part of broadcast ingest. The wider picture, baseband, file-based, and IP ingest, metadata capture, QC gates, and never losing the source, is in Broadcast Media Ingest: How Enterprise Pipelines Actually Work, which frames the discipline as a whole and links out to the detailed guides underneath it, including this one. If you are starting from scratch rather than solving a specific problem, read that first and come back here.

FAQ

Q: What is most likely to go wrong at a corporate live event?
A: Connectivity, followed by remote presenters on domestic wifi, followed by human and procedural problems that a real rehearsal would have caught, unclear running order, presenters outside the shot, slides in the wrong format. Technical equipment failure is comparatively rare.

Q: Where should I spend a limited reliability budget?
A: Redundant internet on different providers first, a second microphone on the main presenter second, and local recording third. Cameras, switchers, and graphics fail less often and degrade gracefully. An event can continue on one camera, but not on a dead connection.

Q: How do I handle a remote executive presenting?
A: Wire them rather than relying on wifi, have them join early for a real test, brief them on framing and lighting in advance, and prepare a fallback, a dial-in audio path or a pre-recorded segment, ready to use if their connection degrades. Remote presenters are the least controllable element of the event.

Q: Do internal events need captions?
A: Yes. The accessibility considerations are the same as for external content, and a substantial share of the audience will watch the recording later. Provide live captions during the event, and replace them with corrected captions on the published recording rather than posting the raw stream.