Production Runbook Lab

In this lab you will build a live-event runbook for a classroom esports production crew. The runbook should make the event safer, easier to run, and easier to recover when something breaks.

A runbook is not a poster or a wish list. It is an operating document. During an event, someone should be able to open it and know what to check, who owns each task, and what to do when a problem happens.

Lab Objectives

By the end of the lab, your runbook should show that you can:

1. define production and moderation responsibilities
2. sequence pre-event, live-event, and post-event work
3. assign clear owners to operational tasks
4. write moderation rules based on observable behavior
5. respond to an incident without improvising under pressure
6. document a backup plan for production failure

Event Scenario

Use your own tournament, scrim, showcase, school club event, or a teacher-provided scenario. If you do not have an event planned, use this default scenario:

• four teams
• single classroom or lab space
• two match stations
• one stream or spectator display
• one scorekeeper
• one production lead
• one moderator
• one adult supervisor

Step 1: Define Crew Roles

List the event crew roles and what each role owns. A strong role assignment makes handoffs clear.

Required roles:

You may add roles if your event needs them.

Step 2: Build the Production Checklist

Create a checklist with at least ten items. Each item must have a timing label and an owner.

Use these timing labels:

• pre-event
• live-event
• post-event

Checklist items should include audio, display capture, scoreboard or bracket visibility, scene transitions, recording location, file names, match start signal, result logging, spectator expectations, and backup equipment.

Example:

Step 3: Write Moderation Rules

Write five moderation rules. Each rule must describe observable behavior, not a student identity or guessed intent.

A usable moderation rule has three parts:

1. behavior that triggers action
2. action the moderator takes
3. escalation path if it continues

Example:

Step 4: Create an Incident Response Card

Choose one likely incident and write the first actions. Use the Week 17 response sequence: pause, document, route, recover.

Possible incidents:

• stream audio fails
• spectator chat becomes distracting
• disputed result
• missing player
• equipment failure
• harassment or disrespectful language
• bracket or schedule error

Your incident card must include:

• incident name
• immediate pause decision
• evidence to document
• owner responsible for the response
• escalation route
• recovery action
• message to teams or audience

Scenario Test

Test your runbook against this event problem:

The stream audio fails during the first match and chat becomes distracting.

Write the exact first five actions for production and moderation. Your answer must identify who acts first, what gets paused or continues, what gets documented, and what message is given to players or audience.

Required Runbook

Submit one runbook with:

1. event context
2. crew role table
3. ten-item production checklist
4. five moderation rules
5. one incident response card
6. backup plan for one production failure
7. scenario-test response

Quality Bar

A strong runbook reduces confusion under pressure. A weak runbook says “fix it” without naming the owner, first action, evidence, or recovery path.

Your runbook is ready when another crew can run the event from it without asking what each step means.