The Paper, Clock and Colour Tools Behind a Reliable Running Order

Every running order we teach begins as a table on a single sheet. It has six columns: segment number, start time, duration, title, owner and fallback. Learners are often tempted to open specialist software on the first day, and I ask them not to. A grid forces you to decide what each row is for before any tool makes the document look finished.

The grid is also the format that survives. A presenter can read it on paper in a dim wing, a producer can paste it into a message, and a technician can print it at the venue when the network is down. Whatever we build later, from cue sheets to handover notes, is derived from this one page.

In these mid autumn weeks, when conference and webinar calendars fill up, I see the same pattern again: the plans that hold are the ones that stayed simple enough to read in ten seconds.

• Segment number, start time, duration, title, owner, fallback
• One sheet per programme, never split across files
• Readable when printed in black and white

The start-time column is calculated, never typed from memory. We write the programme's fixed anchors first: the doors, the opening, any hard end such as a venue curfew or a stream slot. Then we work backwards and forwards from those anchors, adding each duration to the start time above it so that every later time is a consequence of the earlier ones.

We use a plain spreadsheet formula for this, and learners are shown how to read it, not just copy it. When a segment grows by two minutes, every start time below it moves, and the person updating the plan can see at once whether the programme still reaches its fixed end.

We also mark which times are fixed and which float. A fixed time is underlined on the sheet. Everything else is allowed to shift, and the owner of the segment before it knows that.

• Anchors first, then everything calculated from them
• Fixed times underlined, floating times left plain
• One formula per column, checked by a second person

A segment with no owner has no one to ask when it goes wrong. In our grid the owner column holds a name or initials for the person who delivers the segment, and a second set for the person who calls it in from the control side. These are often different people, and writing both prevents the quiet assumption that someone else has it covered.

Owners are also the people we send the draft to before anything is circulated. A presenter who sees their own row, their own start time and the minutes they have been given will correct a wrong assumption in a minute, where a general email to the whole team might go unanswered for a day.

In the course, learners practise this by assigning owners to a sample rundown and then explaining out loud why each person was chosen.

• Delivery owner and calling owner recorded separately
• Draft sent to each owner for their own row first

The last column is the one most plans leave out. For each segment we write what happens if it cannot run as planned: a guest is late, a video will not play, a speaker has overrun. The fallback is a single line, such as skipping to the next segment, shortening to a stated length, or swapping in a pre-agreed alternative.

Writing these lines in advance is calmer than inventing them live. When something slips, the person calling the show does not have to weigh options under pressure; the decision was made earlier, by people who were not rushed. It also shows quickly which segments have no sensible fallback, and those are the ones that deserve more preparation.

We do not aim for a fallback that is clever. We aim for one that someone could carry out in under ten seconds without discussion.

• One line per segment, executable in seconds
• Segments with no real fallback flagged for extra rehearsal

We use very little colour, and always the same way. One tint marks fixed times, another marks segments involving remote contributors, and a third marks changes made since the last version. A legend sits at the foot of the page, so anyone picking it up cold can read it without a briefing.

Version control is equally modest. Each circulated copy carries a version number and the initials of whoever last edited it, and older copies are marked superseded rather than deleted. This avoids the familiar situation in which two team members work from different sheets and only discover it during the first run-through.

Notation follows the same principle: abbreviations are agreed once, listed on the sheet, and never invented mid-document.

• Three tints at most, with a legend on the page
• Version number and editor initials on every copy

By the end of Foundations of the Running Order, learners have taken a rough agenda and produced a one-page grid they can defend line by line. They can say why each start time is what it is, who owns each segment and what happens if it fails. That is a modest outcome, and a useful one.

The module assumes no prior production experience, only a willingness to be precise. Learning activities include rebuilding a deliberately untidy sample agenda, swapping grids with another learner and finding the three weakest rows in each other's work.

Those habits carry into the later modules on timing, cue sheets and handovers, which all start from the page described here.