Recording-Day Run Sheet: Setup, Roles, Interruptions, and Backup Plans

Hello! In the previous lesson, you reviewed the rehearsal as an editor would: you checked the three room voices, noise and distortion, the recorded group shot, and synchronization at both the clap and the end. Any issue you marked “change and retest” still needs a successful short retest before recording day.

Today you will turn those findings into a run sheet: a short, usable plan for who does what, when recording may begin, what to do if something fails, and how to protect the material already captured. The aim is to make good decisions while the session is busy, not to write a long production manual. Allow about 40 minutes, including the readings and adapting the template below.

Build the run sheet around decisions

A recording-day checklist is useful only if it distinguishes checked from ready. “Microphone connected” is a check; “a recorded sample contains all three understandable voices without distorted speech” is evidence that the room audio is ready. Your run sheet should name both the action and the result required to proceed.

Read the technical and day-of portions of How to Prepare for Podcast Recording: Complete Checklist, from The Podcast Studio Glasgow. Use its short-test and interruption-prevention ideas as a starting point, rather than copying its equipment advice unchanged.

For this session, the critical preflight result is specific: the external microphone records the room’s three voices as one usable track, the phone supplies a stable group image without creating a duplicate live room-audio source, and the remote guest—if present—can be heard without their playback returning as echo. A short recorded sample, played back before the episode starts, is stronger evidence than an apparently healthy live preview.

Give each responsibility an owner

A run sheet does not require a large crew. One person may hold several roles, but each task needs an identified owner. Otherwise, the host may assume someone is watching the recording while the operator assumes the host is handling a disruption.

Caspian Studios’ Podcast Roles and Responsibilities describes how production and hosting duties differ. Read it for the principle of assigning responsibilities early; your session can use a much smaller team than the article describes.

On your run sheet, operator means the person controlling Riverside, checking the recording, noting take identifiers, and calling a technical stop. Host means the person guiding the conversation and telling participants when to pause or repeat a thought. These may be the same person, but write down that choice. Ask all three in-room speakers to help by staying reasonably oriented toward the shared mic and signalling if they notice a problem. If there is a remote guest, agree that they will use their checked microphone and headphones and wait for the host’s cue after a disconnection.

The editor is not a live-session safety net. The editor can work with a well-labelled interruption; they cannot reconstruct words that were never recorded or separate three room voices captured on one microphone.

A recording-day run sheet you can adapt

Keep this somewhere the operator can see it without covering Riverside. Replace the bracketed fields before the session. Times are relative to the planned recording start; adjust them to allow enough setup time for your room and guest.

Session header: Episode/topic [ ]; date [ ]; planned start [ ]; operator [ ]; host [ ]; in-room speakers [three roles or seat positions]; remote guest [yes/no]; agreed off-platform contact method [ ]; rehearsal issue requiring confirmation [ ]; primary take identifier [ ].

1. About 45 minutes before — operator prepares the system. Check that the room is quiet enough; reduce controllable noise and interruptions. Connect computer and phone power, confirm available storage and a stable internet connection, open the intended Riverside studio, and verify browser permissions and recording settings. Select the external room microphone and phone group camera. Confirm that the phone or another device has not also become a live room microphone. Place and frame the three speakers using the arrangement that passed rehearsal. Start the tested backup recorder, if one is available, and confirm that it is actually recording.

2. About 20 minutes before — operator and host check participants. The operator has each room speaker talk at normal volume and briefly louder volume, watches for overload, and checks that the group stays in frame. If a remote guest is joining, bring them in early enough to check their selected mic, headphones, picture, and connection. Verify that the room can hear them without delayed echo. The host confirms how to signal a pause and, if the guest disconnects, how to reach them outside the recording call.

3. About 10 minutes before — operator records and reviews a short sample. Include all three room voices, the remote guest if present, a short exchange, and a view of the group shot. Play back the recorded sample. Proceed only if speech is understandable and not repeatedly distorted, no troublesome echo is present, and everyone remains visible. Confirm the backup has captured sound too; its meter or timer alone is not proof. Apply and retest any unresolved rehearsal fix. If the remote guest is absent, record “remote not tested,” not “remote passed.”

4. At the start — operator and host establish the take. The operator announces the take identifier and confirms Riverside is recording; the host waits for that confirmation before beginning. Make a visible, audible synchronization clap as rehearsed, then allow a moment before the introduction. The operator notes the approximate start time and watches the recording, connection, and upload indicators while the host leads the discussion. Note interruptions against the take identifier rather than trying to remember them afterward.

5. At the end — operator protects the files. The host clearly ends the conversation; the operator stops the recording and notes its end. Keep the relevant devices and Riverside session available until uploads have completed. Check that the expected room audio, group video, and any remote track are present; do not treat an upload still in progress as delivered material. Record any missing track or unresolved warning for the editor.

This is a go/no-go plan, not a promise that every technical problem has a quick fix. If the sample fails, leave time to change one likely cause and record another sample. Do not begin a long episode on the assumption that the editor will repair repeated clipping, an inaudible speaker, or a missing camera track.

Write interruption procedures before you need them

A useful interruption instruction has three parts: who calls the stop, what happens to the conversation, and how the next usable section is identified. Agree on a simple spoken cue such as “Pause for a technical check.” The host then stops the discussion; the operator investigates and logs the approximate point. On resumption, announce a new take identifier or a clear restart point, leave a brief pause, and ask the host to restart from a complete question or thought. That gives the editor a clean boundary.

Plan the backup according to what it can actually capture. A separately powered, tested recorder—or a second phone used solely to record backup audio—can protect the room conversation. Put it where it can hear all three voices, check its storage and power, and listen to a sample beforehand. It does not automatically provide a backup group video or a clean, separate track of the remote guest. Do not count the phone already serving as the Riverside camera as an independent backup unless you have specifically tested that it can perform both jobs at once.

If there is no separate backup device, write that down rather than listing an imaginary one. Your practical fallback is to pause, preserve what exists, repair and retest, then resume as a new take. If the group camera fails, decide in advance whether an audio-only continuation is acceptable to the people responsible for the episode; otherwise stop and reschedule. If the remote guest cannot reconnect with a usable recording setup, pause or reschedule that portion rather than accepting an unintelligible contribution. These decisions protect the editor from receiving material whose limitations were never agreed.

Conclusion

Your run sheet is ready when someone else could use it to answer four questions under pressure: Who is responsible? What result permits recording to start? What happens when the session is interrupted? What material does the backup actually protect? Carry forward any unresolved rehearsal finding as a named preflight check, and keep take identifiers and interruption notes as you work.

The next lesson will focus on the editor handoff: confirming that original tracks have fully uploaded, naming them consistently, and passing along concise notes about the takes and any limitations.