Planning on-site broadcast support so your crew is never left guessing

Before anyone is booked, write down what the programme asks of the technical side. A half-hour regional news bulletin with two presenters and a remote guest needs different cover from a three-hour live event with several cameras and a changing guest list. List the sources, the outputs, the number of people in the gallery and the points where something could realistically fail.

I begin every support plan with a short conversation about the last time something went wrong on air. The answer is usually specific: a radio mic that dropped out, a graphics feed that froze, an intercom channel nobody could find. Those incidents tell us where a support engineer will earn their place far better than any generic checklist of equipment.

Keep the document to one page. If it runs longer, it will not be read at 6 a.m. on the day of the broadcast.

• Sources and outputs the programme depends on
• Number of people in the gallery and on the floor
• Known weak points from earlier broadcasts
• Start time, rehearsal time and get-out time

On-site support comes in two forms, and it helps to choose deliberately. An engineer in the gallery can hear the problem as it happens, see the faces of the crew and act without explaining. Remote support by phone suits stable, well-rehearsed shows where the risk is low and the in-house team knows the system.

For a first live broadcast from a new or rebuilt studio, I recommend having someone physically present. For a routine programme that has run smoothly for months, a named contact on the phone, who knows the room and has the wiring diagrams to hand, is often enough.

Whichever you choose, agree it in writing. State who the person is, where they will sit, which decisions they may take without asking, and who the in-house crew should call if the engineer is already dealing with something else.

A rehearsal that only proves the programme works when everything goes well is half a rehearsal. Spend a portion of the session deliberately breaking things: pull a camera feed, mute a microphone, drop the connection to a remote guest. Watch how the crew responds and where the confusion sits.

The aim is not to catch people out. It is to find out whether the fallback procedure written on paper survives contact with a busy gallery. Often it does not, because a step assumes someone is free to carry it out, or a label on the desk no longer matches the routing.

Record what you learn on the run sheet itself. After two or three rehearsals the fallback steps shrink to a few lines that people can recall under pressure, which is exactly how they should read.

• Lose one camera and switch to the wide shot
• Lose a presenter microphone and move to the backup
• Lose the remote guest and cover with a prepared item

The best outcome of a support engagement is that you need less of it next time. Practical training, done at the desk with your own equipment and your own programme, does more than a classroom session ever could. People learn the vision mixer by running the show they will actually run.

I prefer short sessions in small groups, ideally split by role: operators on cameras, the person on the mixer, whoever looks after audio. Each group needs different habits, and mixing them tends to bore everyone. Leave time for people to ask the question they were embarrassed to raise in front of colleagues.

Write a one-page reference for each role afterwards, using the labels and settings of your own studio. A sheet that says which button does what on your desk is used for years; a manufacturer manual is used once.

When the programme finishes, the support job is not quite done. Take ten minutes with the crew while memories are fresh. What was awkward, what nearly went wrong, what did the engineer have to change on the fly? Those notes are the most honest account of the system you will ever get.

Turn them into a short list of actions with a name beside each. Some will be small, such as relabelling a patch bay or moving a monitor so a floor manager can see it. Others may need a proper change to the setup and a proper conversation about cost.

Keep the list with the run sheet so the next team sees it before they start. Continuity of this kind is unglamorous, but it is what makes a studio feel calm rather than improvised.

• Name an owner for each action
• Note anything changed during the show
• File the list with the run sheet