Studio AV
Technical 17 February 2026

Why corporate events go down on the day (and what to demand from your AV vendor)

Audio cutting out, the stream freezing, lights coming up at the wrong moment. The failures that ruin corporate events aren't random. They're predictable, and almost all of them are preventable.

By Studio AV team

Everyone has a story. The keynote where the mic died and the speaker had to shout. The product launch where the LED wall flickered out during the reveal. The AGM where the CEO’s webcam froze on a face that looked unfortunate, for nine seconds, in front of 4,000 shareholders.

These stories get told as bad luck. Most of them aren’t bad luck. They’re predictable failures with known countermeasures, ignored at the proposal stage to save a few hundred dollars and exposed at the moment that costs the most.

Here are the failures we see most often in corporate AV, what causes them, and what to ask your vendor to put in place before signing.

The audio dies and the speaker has to shout

The most common cause: a wireless microphone battery runs out mid-presentation.

This happens because batteries don’t fail predictably. A “full” lithium pack might read 90% for two hours and then drop to 0% in 15 minutes. If the operator at the back of the room isn’t watching transmitter battery levels actively, they don’t know it’s happening until the audience starts wincing.

Countermeasure: a disciplined battery-swap schedule. Every wireless transmitter gets a fresh pack every 90 minutes regardless of what the meter says, with the spent packs going on the charger to be ready for the next swap. The cost is some batteries and 30 seconds of operator attention per swap. The risk avoided is the moment that ruins the presentation.

A more subtle version: the operator changes batteries at the break but a meeting overruns, the next session starts on the same pack, and the death happens 70 minutes in instead of 90. Solution: hot-swap during a presenter handover instead of waiting for breaks.

What to ask: “What’s your wireless battery management protocol, and what’s the standby procedure if a mic dies live?”

The stream freezes at the worst possible moment

Two causes, both common.

The first: the venue’s internet drops or throttles. Big conference centres often have many tenants sharing one pipe. Your stream is competing with the next-door event’s catering POS, the badge printers, every attendee’s phone, and whatever marketing team is uploading photos from their laptop. At peak times the available outbound bandwidth can collapse without warning.

The second: the encoder hangs. Streaming encoders are computers running real-time encode pipelines, and computers occasionally lock up. A single-encoder setup with no failover means the stream goes down until someone physically restarts the box, which is the worst time to find out your hardware needs a hard reset.

Countermeasure for venue internet: bonded uplinks. Venue wired internet as primary, with a 4G or 5G modem as failover. The encoder is configured to auto-switch when the primary drops below a quality threshold. Viewers see a brief bitrate dip and nothing else.

Countermeasure for encoder failure: redundant encoders running in parallel. One is live to the stream destinations; one is hot-spare, encoding the same inputs and ready to be switched in. Manual failover takes about three clicks at the vision desk.

Both add a few thousand dollars to a hybrid event budget. Both pay for themselves the first time they’re used.

What to ask: “If the venue internet drops or the encoder hangs, what happens to the stream?” The answer should involve specific failover hardware, not “we restart it.”

The vision cuts to black

Causes, in rough order of frequency:

  • A camera operator pulls the wrong cable.
  • An SDI cable fails (intermittent connection, usually invisible until the bend that breaks it).
  • An LED panel loses sync with its processor.
  • A vision switcher freezes (rare, but it happens).
  • A projector overheats and shuts itself down.

Most of these are addressed with the same general approach: have a spare you can switch to quickly. For cameras, that means a backup PTZ pre-rigged at FOH that can cover the locked-off main shot. For LED, that means spare processor modules at the panel array. For projectors, that means twin projectors in stack mode where one fails over to the other (or at minimum, a spare bulb ready to swap during a break).

The cable failures are trickier because they’re intermittent. Solution: every critical signal path has a parallel backup cable run during install, terminated and ready to go. If the live cable starts flickering, the operator switches inputs at the destination, not at the camera.

What to ask: “If the main camera goes dark, what’s the backup, and how fast can you switch?”

The lights come up at the wrong moment

Causes:

  • The lighting operator missed a cue.
  • The DMX universe dropped (rare).
  • The console crashed (rare, but ETC EOS can lock up under specific edge conditions).
  • The cue list got out of sync with the run-of-show because somebody changed the run-of-show 45 minutes before doors and didn’t update the cues.

The first cause is human and addressed by having a senior LD who’s rehearsed the show, not a junior who’s reading the cue list cold.

The DMX and console issues are addressed by redundancy: backup console hot-paired with the main, ready to take over via a manual switch. ETC’s protocols support this natively. Cheap to enable.

The fourth cause is the most common and the most preventable. If your run-of-show changes the day of, your lighting cues need updating to match. The senior LD should know to ask. If they don’t ask, your production manager should be loop-checking.

What to ask: “If the show structure changes the day of, what’s your process for updating cues?”

The recording is corrupt and you can’t recover it

This one usually surfaces a week after the event when someone goes to edit the highlight reel and discovers the files are unusable. Causes:

  • The recording device’s SD card was full and the recorder silently stopped.
  • The recording was set to a codec the editor can’t decode.
  • The audio recording wasn’t synced to the video.
  • The recording happened but only at the live stream’s compressed bitrate, not at source quality.

All preventable. The countermeasure is process: a pre-event recording test (record 5 minutes, verify it opens cleanly in your editor, confirm sync). A second recording on a separate device for redundancy. A handoff at the end of the event where the production manager confirms file delivery in writing.

For events where the recording matters more than the live stream (training content, regulated proceedings, content with a long second life), record ISO from every camera independently, not just the program output. ISO recording costs more in storage and post-production time, but it lets you re-cut the show months later when needs change.

What to ask: “What’s your recording chain, and how do I know on the day that it’s working?”

The presenter’s laptop won’t talk to the projector

Classic. Resolutions don’t match, the laptop’s HDMI is USB-C only and the cable isn’t, the cable is a DisplayPort the projector doesn’t accept, the laptop is on a different scaling factor and the slides look tiny. The presenter is at the lectern, the room is waiting, somebody’s frantically swapping dongles.

This is preventable in two ways:

  1. Tech check every speaker the morning of, with their actual laptop, on the actual projection path, with their actual slides. 10 minutes per speaker. Catches the dongle problem when you can fix it, not when you can’t.

  2. Stage management dongles and adapters. Every common port, every common adapter, all in a clearly labelled kit at FOH. USB-C to HDMI. USB-C to DisplayPort. HDMI to DisplayPort. Mini-DisplayPort to HDMI. Type-A to Type-C. Whatever the latest MacBook is doing for its outputs that quarter.

The cost is a few hundred dollars of cables and 90 minutes of tech-check time. The cost of not doing it is the moment everyone remembers.

What to ask: “What’s your tech check process for presenter laptops?”

The venue staff and your AV crew get in each other’s way

This isn’t an equipment failure but it’s the most common cause of bump-in delays. Venue operations teams have their own protocols for power patching, rigging point access, dock loading, and safety sign-offs. Production crews who don’t know the protocols delay themselves by hours.

The countermeasure is the site visit, done early enough that any protocol surprises can be planned around. A vendor who’s worked the venue before should know the venue ops manager’s name, the loading dock cutoff times, and the rigging point inspection requirements.

What to ask: “Have you worked this venue before? Who’s your point of contact in their ops team?”

The pattern

All of these failures share a structure: predictable, known to experienced crews, addressable with specific countermeasures, ignored at the budget-saving stage, exposed at the worst-cost moment.

The good news: a vendor who answers all of the above questions concretely is a vendor who knows. The bad news: not every vendor does, and you usually can’t tell from the proposal alone.

This is why the discovery call matters. A vendor talking about their redundancy protocols, their battery management, their site-visit routine, their tech-check process. That is a vendor who’s been in the room when the things went wrong, and decided to put in the work so they don’t go wrong again.

A vendor who tells you their gear is reliable, their team is experienced, and everything will be fine. That is a vendor who hasn’t been in that room yet.

Pick accordingly.

More on Technical

Call Request proposal