Building Your Autumn Running Order Before the Busy Season

Mid autumn is when many business events, member evenings and streamed discussions move from idea to date. Agendas arrive as a few lines in an email: welcome, two talks, a panel, close. That is a fine starting point, but it is not yet a running order. The gap between the two is where most last-minute stress comes from, and the coming weeks are the best moment to close it.

A running order is a sequence of segments, each with a start time, a length, a named owner and a note about what happens if things slip. When I teach the foundations module, I ask learners to produce that structure before anything else is polished. Slides, music and lighting ideas can wait. A clear sequence tells everyone what the day is, and it gives every later document, from cue sheets to rehearsal plans, something solid to hang from.

Start by splitting the draft into segments that each do one job. A welcome is one segment. A keynote is another. A panel may be three: introduction of guests, discussion, audience questions. Number them in order and give each a working title that the whole team will use. Shared names prevent the small confusions that grow when one person says opening remarks and another says intro.

Next, give every segment a length in minutes and add them up against the total slot you have. If the sum is longer than the programme, you have found the problem on paper rather than on the night. Resist the urge to squeeze each item a little. Decide which segment can lose time, and write that decision down so the choice is made calmly rather than under pressure.

• One job per segment, one working title per segment
• Lengths in minutes, added against the total slot
• Note which segment is allowed to shrink

Once lengths are set, work out start times from the top and write them in plainly, in the format your team reads fastest. Many learners add a column for the owner of each segment: the person responsible for it starting on time and handing over cleanly. This is the column that is most often missing from a draft agenda, and it answers the question that comes up on every show: who decides when this item is finished?

An owner is not always the person on stage. For a talk it may be the moderator; for a video playback it may be the technician. Naming one person per segment keeps responsibility from drifting between two people who each assume the other has it. In a short rehearsal, reading the owner column aloud will quickly show you where a name is missing or doubled.

Autumn brings its own small risks: earlier darkness for evening arrivals, travel delays as weather turns, and speakers juggling a crowded diary. A good running order carries a fallback for each segment that matters. This does not need to be elaborate. It can be a sentence: if the guest speaker is late, move the panel forward and open with the sponsor message.

Write fallbacks next to the segment they protect, not in a separate document that nobody opens mid-show. Keep each one short enough to read in a few seconds. In class we test them by deliberately removing a speaker from a sample rundown and asking the group to run the revised sequence. The plans that survive are the ones simple enough to follow without discussion.

• Late speaker: which segment moves up
• Overrun: which segment is trimmed first
• Technical fault: what the host says while it is fixed

Before the running order goes to presenters and technical staff, read it once from the point of view of each reader. A presenter wants to know when to be ready and how long they have. A camera operator wants to know what comes next and when. Someone arriving cold should be able to run the show from the page, which is the standard the handover module builds toward.

Check that start times add up, that every segment has an owner, and that the document has a version number and a date in its file name. When a change arrives, which it will, update the same file and tell people what changed. Over a busy autumn, that small habit prevents three people working from three different versions of the same programme.