Contents
There is one document that every person backstage reads again and again, and that not a single guest ever sees.
At most events I have worked on, that document is the run of show: the time-coded script of an event, giving every segment its start time and duration, who is on stage, what each technical team has to do, who is responsible and what signal starts the moment. The presenter glances at it between introductions, the sound engineer keeps it beside the mixing desk with microphone numbers circled, the stage manager carries it folded in a back pocket, and the hotel’s banquet captain has a copy near the kitchen door. Guests receive something far shorter, and they never need to know the longer version exists. Yet everything they experience in the hall corresponds to one of its rows.
A definition like that makes it sound like a timetable, and that is exactly the trap. A timetable describes what is supposed to happen. A run of show has to describe what people will actually do, including the walking, the waiting, the microphone being adjusted and the lights changing between one item and the next.
That difference is the reason so many runs of show look tidy in the office and fall apart in the first hour. The tidy version lists the content, the speeches, the panel, the video, the award, the performance, and leaves out the human and technical movement that connects them. It also tends to be written once and then copied, edited and forwarded by several people, until the sound desk and the presenter are no longer holding the same document.
Most of my years in operations, first on the client side and now at Flex Event, have convinced me that writing a run of show is not difficult. Writing one honestly is harder, and keeping it identical in every hand that holds it is the hardest part of all.
Two documents for two readers
The agenda and the run of show are often treated as one file, and that is where much of the confusion begins. The agenda tells guests what will happen: an opening, a keynote, a panel, lunch, an award ceremony, a concert. It belongs in the invitation, the congress app or the printed booklet. The run of show tells the team how it will happen, minute by minute and person by person. On a corporate day the same split applies to an afternoon of team building activities, which the agenda gives a cheerful name and the run of show breaks into briefings, group changes and equipment moves.
Because the readers are different, I think the documents should be too. The guest version works best with rounded times and plain titles, since guests read precise minutes as promises and a ten-minute slip looks to them like a failure. The technical version needs precision, sometimes down to the second for a video or a walk-on. When one file tries to serve both, either guests find lines like “handheld mic 2 ready” in their booklet, or the crew works from rounded times and guesses when to roll a video by watching the presenter’s face.
Official ceremonies in many countries add a third version for the protocol teams accompanying senior guests, showing arrival time, the entrance they will use, the length of their remarks and when they depart. The order of speakers follows protocol rules of its own; the run of show only translates that order into minutes.
What does a row need to say?
A good run of show reads almost like a table, even when it lives in an ordinary word processor file, which is how most of them begin in our market before circulating as PDFs in messaging groups. Whatever the format, each row has to answer the same few questions:
- when it starts and how long it lasts
- what happens, and who is on stage or on the floor
- which microphone is live, what the lights do, what plays on which screen and whether music runs underneath
- who is responsible for the row
- what cue starts it
The last of these matters more than all the others.
Cues are the working language of the document. “When the presenter says the speaker’s name.” “When the applause ends.” “When the video finishes and the screen goes black.” These are the signals the lighting desk and the video operator actually wait for, and at a hybrid event the streaming director waits for them too, because the online audience sees every late cue.
A time on a run of show is a target; the cue is what actually starts the moment.
A row with a time and no cue leaves each technical team to decide on its own when the moment begins, and three people deciding independently rarely decide the same thing.
Transitions deserve their own rows
Most runs of show list the speeches with care and skip the moments between them. Yet the walk from the front row to the stage steps, the presenter’s introduction, the speaker adjusting the lectern microphone to their height, the name on the screen changing, the lights dimming for a video and coming back afterwards each take a minute or two, sometimes more.
In a program full of transitions, those unwritten minutes add up to a real delay, and the event falls behind within the first hour without anyone being able to explain why. By the afternoon the session the client cared most about starts in a half empty hall, and that lost hour quietly eats into the return on an event everyone will be asked to report later. Giving each transition a row of its own fixes two problems at once: the minutes become visible, and every transition gets a name beside it. Who brings the speaker to the steps, who fits the lapel microphone, who starts the video, who carries the lectern off when the stage changes for a panel? Once the row exists, so does the answer, and nobody ends up standing at the side of the stage waiting for someone else to move.
Where should the buffer go?
Buffer time is the handful of minutes left in the document on purpose and assigned to nothing. Many teams add it as a single block at the end of the day, which is the least useful place for it, because by then the delays have already pushed everything else.
I find it works far better spread behind the moments with the most uncertainty. Openings need it, since halls in our part of the world rarely fill at the announced time and senior guests’ arrival times are often confirmed only at the last moment. Blocks of speeches need it, because durations slip most there. Stage changes need it, because one loose cable can cost five minutes by itself.
The buffer also deserves its own row and its own label. Folded quietly into the next segment, it gets used by whoever runs that segment, who naturally assumes the extra minutes are theirs. Sitting on the page as unassigned time, it stays available for whatever actually goes wrong.
Rehearsal turns guesses into minutes
A run of show written at a desk is mostly a set of good intentions, and its durations become real only when someone tests them. The first test happens with the speakers, well before the day. In my work, and I suspect in most places, speaking invitations are often made by phone, with phrases like “a short welcome” or “a few words”, and those phrases mean two minutes to one person and fifteen to another. Telling each speaker their time in writing, in minutes, with a copy to their office and a note of who speaks before and after them, solves most of the problem in advance. I prefer to send each speaker their own row together with the one before and the one after, rather than the whole document, so they see at a glance when to be backstage, who introduces them and how long they have.
The second test is rehearsal, often the first line cut from the event budget because an extra half day of crew and hall costs money. Someone sits with the document and a stopwatch and writes the real duration next to every row. That is where you find out that the opening video is longer than its file name suggests, that the walk to the lectern is shorter than you assumed, or that the stage change before the concert needs considerably more time than you gave it. After rehearsal the document is rewritten with those measured numbers, and only then does it describe the event rather than the hope of one.
One owner, one timestamp, one radio call
The document keeps changing until the last moment. A speaker cancels, a guest is added, an artist’s team moves their slot. The change itself is rarely the problem; the problem is a change that reaches some people and not others.
Different teams need different views. The presenter wants the rows merged with their script, the sound desk wants microphone numbers, the lighting desk wants cue states, the video operator wants file names and screen assignments, and outside the stage the banquet team needs service times, security needs door times for its crowd management plan, and transfer drivers need arrival and departure times for guests. The usual mistake is to write each of these separately, so that the first change updates two of them and leaves the third behind. Whether it sits with the client or the organization company, what has served me best is a single master with one owner. Anyone can ask for a change, but only the owner edits the master, and every other version is filtered from it rather than retyped. Each version carries the date and time of the update in its top corner and in its file name, which ends the familiar confusion of messaging groups full of “final”, “final 2” and “final last”, and a line or two summarising what changed travels with every new version so that a technician does not have to compare forty rows to find one moved segment. Collecting the old printed copies matters as much as handing out the new ones, because yesterday’s sheet left on a table becomes someone’s current version the next morning.
None of this turns the document into a safety plan, and it should not pretend to be one. The UK Health and Safety Executive’s guidance on managing an event puts the weight on coordination and monitoring through every phase, which the run of show supports with times and names, but when a crowd builds at a door or a stage element looks wrong, the call to hold a segment belongs to the person the safety arrangements name. I like that name to appear on the first page of the run of show, so that nobody carries on simply because the next row says it is time.
Once the doors open, reprinting is rarely possible and changes are made by pen, so the safest habit I know is for the stage manager to read every change aloud on the radio and have each team mark the same note on its own copy at the same moment. That is also why, a few minutes before the doors open, the most useful thing a stage manager can do is to walk past the sound desk, the presenter and the banquet captain and ask each of them one simple thing: which version are you holding?