From Draft Agenda to Running Order: A Step-by-Step Walkthrough

Most running orders begin as something untidy: a forwarded email, a list of topics, a few names with question marks beside them. Before you build anything, copy the draft out exactly as it arrived and read it twice. On the first pass, mark every item that is a real segment, meaning something the audience will see or hear. On the second, mark everything that is only a wish, such as a vague line saying greetings and some audience moments. This early sorting saves the most time later. In streamed discussions I coordinate, the first pass usually turns eight loose lines into five true segments plus three items that need a decision from the organiser. Write those open questions on a separate list, because a running order that hides unresolved items will fail at the worst moment.

Keep the original draft in your folder, untouched. When a presenter later says that was not what they agreed to, you can point to what was written and show what changed and why. That habit is not about blame; it keeps the team working from the same page. Give each version a simple number and a short note on what moved, so anyone joining late can follow the history without a phone call.

• Copy the draft out unchanged and keep it
• Mark real segments separately from wishes
• List open questions for the organiser

A segment is a block of programme that has one purpose, one owner and one clear end. A topic such as audience questions is not yet a segment. It becomes one when you write who runs it, what has to happen in it and how you will know it is finished. For example: moderator takes four pre-submitted questions, panel answers each in under ninety seconds, moderator closes with a thank-you. If you cannot describe the end of a segment in one sentence, it is probably two segments wearing one name. Split it. Short, single-purpose segments are easier to time, easier to cue and far easier to cut when the programme runs long. They also make handovers cleaner, because the next owner can see exactly where their part begins.

Give every segment a short label that the whole team will use out loud, such as Open, Panel A, Remote Guest, Questions, Close. Those labels appear in the running order, the cue sheet and the rehearsal plan. When a technician says go to Remote Guest, nobody should need to ask what that means. Choose labels early and resist renaming them halfway through, because every rename must be repeated in every document.

• One purpose, one owner, one clear end
• Split any segment you cannot end in one sentence
• Use short labels the whole team repeats aloud

Start from the fixed points: the moment the stream goes live and the moment it must end. Everything else is arithmetic you do backwards and forwards from those two times. Write each start time as a clock time, not only a duration, so that a person glancing at the page knows instantly whether the programme is on schedule. Add the planned length in a separate column. Next to every segment, put one name. Not a team, not two people, one person who is responsible for that segment starting well. If a moderator introduces a guest and a technician brings in the guest's video, the owner of the segment is still the moderator, and the technician's action belongs on the cue sheet. Single ownership prevents the quiet confusion where each person assumes the other is watching the clock.

Check the sum before you share the plan. Add the planned lengths and compare them with the gap between the fixed points. If the segments fill the slot exactly, you have no buffer, and the plan is too tight. A small gap left unassigned is not wasted time; it is the space where real programmes absorb a late guest, a slow microphone check or a longer answer than anyone expected.

• Work backwards from the live time and the end time
• Use clock times and a separate planned-length column
• One named owner per segment, never a group

A fallback is a decision made calmly in advance so it need not be made nervously during the show. For each segment that depends on something that might fail, write one line: if this goes wrong, we do this instead. A remote guest whose connection drops can be replaced by the moderator reading the guest's written answers. A video clip that will not play can be skipped, with the moderator carrying on from the next prompt. Keep fallbacks short and honest. They are not a second programme. Each should be something the presenter could do without extra preparation, and each should name who calls it. In my experience the call is best given to one person, usually the producer or stage manager, so the moderator is never asked to judge technical trouble while also hosting.

Mark which segments can be cut and which cannot. When time runs short, the team should already know that the second round of questions goes before the closing remarks do. Writing that order on the running order, perhaps as a simple cut-first and cut-last note, turns a stressful improvisation into a quiet instruction. Rehearse at least one fallback in your walkthrough so the team has heard it spoken once before it matters.

• One fallback line per risky segment
• Name the person who calls each fallback
• Mark what is cut first and what is protected

The finished running order is a working tool, so its layout matters as much as its content. Use a plain table with a few columns: start time, label, owner, planned length and fallback. Keep the type large enough to read at arm's length in a dim control room, and avoid colour as the only way of showing something, since printed copies may come out in grey. Put the title, version number and the live time at the top of every page. If the plan runs to two pages, repeat those details on the second. A page that has lost its version number is a page someone will eventually run from by mistake. Print a few copies, and make sure the digital version the team opens is the same one.

Finally, read it aloud once as if you were the moderator, then once as if you were the technician. Listen for any line that makes you hesitate. Hesitation on the page becomes hesitation on the night. Fix those lines, update the version number and send the plan to everyone with a short note listing what changed since the last version. That note is small, but it is what keeps a team of several people working from one shared picture.

• Table columns: time, label, owner, length, fallback
• Title, version and live time on every page
• Read it aloud in two roles before sending