Livestream Run Sheet: Preparation, Moderation and Follow-Up

Use this run sheet before you go live: define one session purpose, verify the current account surface, assign host, moderator and technical owners, prepare timed segments with transition cues, write pause and end triggers, and open a follow-up ledger before the session starts. During the stream, record questions and commitments instead of relying on memory. After it ends, close every promise, unanswered item and reusable asset with a named owner.

Write the session promise and operating roles

Start with a one-sentence promise a viewer could understand: “A live wardrobe planning session with three prepared looks and time for general questions.” Avoid vague goals such as “boost engagement” because they do not tell the host what to deliver. The promise should match prepared material and creator boundaries. If the event depends on a guest, asset or current platform control, name that dependency.

Assign roles to people, not departments. The host controls pacing and on-camera choices. The moderator triages comments or questions using the creator-approved guide. The technical owner watches the connection, audio, framing, power and any approved capture process. One person may hold several roles in a solo session, but the sheet should still list the role changes so important checks are not silently skipped.

Verify the current platform surface in the actual creator account before finalising the run. Record what the team can observe and use today; do not copy a feature list from an old guide or another account. The run sheet intentionally does not claim that a specific visibility, replay, payment, moderation or notification control is universally available.

Complete the Pre-live control block

The Pre-live control block is a go, hold or stop review. Confirm the brief version, audience promise, creator-approved boundaries, role owners, device power, stable connection, sound check, framing, background, notifications, required assets and fallback. Record the time each item was checked. A check mark without a time or owner cannot tell the team whether the state was current.

Open every asset from the device that will use it. Check links, filenames, playback, orientation and sound. Put the fallback asset beside the primary one. If a segment uses notes, shorten them to cues rather than a full paragraph the host must read. Keep personal records, private messages and unrelated browser tabs out of the presentation path.

Rehearse the opening, one transition, a boundary response, a technical pause and the close. The rehearsal is not a performance. Its job is to find missing owners, ambiguous cues and assets that do not load. Record the actual rehearsal duration only as local planning evidence; it is not an ideal livestream length or a benchmark for other creators.

Set a final go decision and a latest start decision. If a required safety, identity, access or technical check is unresolved, choose Hold. Starting on time is not more important than knowing what the team can safely and accurately deliver.

Build a Segment clock with cues and fallbacks

The Segment clock is a sequence of rows, not a rigid script. Each row needs a start cue, planned duration, purpose, host action, moderator action, asset and transition cue. Use relative cues such as “after welcome confirmation” or a running session time. Keep one person responsible for the clock so the host is not repeatedly checking a device.

Give every segment one job. An opening establishes the promise and interaction expectations. A prepared content block delivers the core value. A question block handles suitable queued items. A close restates only commitments the team recorded. When a segment tries to introduce, demonstrate, answer every question and promote the next event, the team cannot tell which part to shorten.

Add a fallback for the elements most likely to be unavailable: a missing guest, failed media file, noisy environment or empty question queue. The fallback should already fit the session promise. Do not fill time by making an unreviewed offer, revealing personal information or committing to content that has not been scoped.

Operate a Moderation queue instead of improvising

The Moderation queue captures the substance of a question, its time, state and owner. Use states such as Answer now, Hold for creator, Follow up, Decline, Technical and Duplicate. The moderator can combine repeated suitable questions, but should not change their meaning. If the team cannot verify an answer during the session, say it will be checked and place it in follow-up.

Prepare a short boundary cue in the creator's voice. It should close the topic and return to the session without debate. The moderator should not negotiate boundaries or invent exceptions in public. When a request is uncertain, preserve a minimal private reference and escalate through the creator's normal process; do not paste unnecessary personal or intimate detail into the run sheet.

Separate moderation from audience interpretation. A busy queue does not prove a topic is successful, and a quiet period does not prove viewers are disengaged. Record observable events: number of suitable questions received, duplicates, unresolved items, technical interruptions and segments completed. Use the subscriber retention guide for the broader relationship strategy rather than turning a single live session into a retention claim.

Give the host a clear visual or verbal cue for Pause, Skip and End. A moderator should not need to explain a complex issue live. The host acknowledges the pause, uses the prepared transition and waits for a go signal or moves to the next segment.

Write failure branches before the session

List a small set of observable failures and the first safe action. If sound fails, pause the content, confirm the issue from the monitoring path and move to the tested audio backup or end. If connection quality becomes unreliable, stop adding new commitments while the team checks state. If an asset fails, use the named fallback or skip. If a boundary issue appears, the moderator applies the approved state and the host continues.

Do not promise that a reconnection, replay or recovery option will behave a particular way. Record what the current account shows and what happened. A good branch preserves the creator's next decision: continue, pause, reschedule, publish a separate update or close. It does not depend on a platform behaviour the team has not verified.

Close the Follow-up ledger before evaluating the session

The Follow-up ledger begins during preparation with owners for unanswered questions, promised assets, approved clips, replay review and the next-session note. During the stream, the moderator adds each commitment in the speaker's exact meaning. After the close, the team assigns a due window and evidence. “Send later” is not a completion state.

Review any saved media through the creator's normal quality and boundary process before reuse. Record the source timecode, proposed job, edit owner and approval. A clip that was appropriate in a live sequence may need different context when separated. Do not treat the presence of a recording as permission or readiness to publish it elsewhere.

Run the retrospective only after operational items are captured. Compare plan with execution: segments completed, changes, technical pauses, unanswered items and commitments closed. Choose one process adjustment, such as shortening a transition cue or opening the question queue earlier. Do not infer revenue, loyalty or audience preference from this operating record alone.

Copy the full livestream run sheet

Worked example: a prepared styling session

Consider a fictional session whose promise is to compare three prepared looks and answer general styling questions. The run has a welcome, three look segments, one queued-question segment and a close. Each look has a labelled asset bundle. A pre-recorded detail clip is the fallback if a live camera angle fails. The boundary cue declines personal requests and returns to the styling topic.

During look two, the detail camera stops responding. The technical owner signals Hold; the host uses the transition cue; the prepared clip runs; and the moderator marks the segment change. Two questions require information the creator does not want to guess, so they move to Follow up with an owner. The close repeats only the next-session date that was already confirmed.

Afterward, the team closes the two questions, reviews one clip candidate, records the technical failure and changes the next rehearsal checklist. Nothing in the example assumes a viewer count, sales outcome, replay feature or ideal duration. Its value is the clean handoff between prepared intent, live decisions and completed follow-up.