Ontaym
Event Production & Logistics

The Agenda Is for the Room. The Run-of-Show Is for Everyone the Room Never Sees

Ontaym Editorial Team · · 16 min read

A team gathered around a conference table with laptops and notes, working through an event plan together

Every event has an agenda. Almost no small event has a run-of-show, and the difference between them is the difference between knowing what happens and knowing who makes it happen. One is a promise to the audience. The other is an instruction set for the people standing in the dark at the side of the room.

Quick answer

An agenda is audience-facing and measured in blocks: a keynote at nine, a panel at ten. A run-of-show is crew-facing and measured in minutes, sometimes seconds, and it assigns a named human to every transition.

The failure mode is not the content going wrong. It is the ninety seconds between two content blocks, where nobody was told whose job it was to turn on a microphone.

Professional productions solve this with a single master timeline that carries every department in parallel columns, so one row of the document tells you simultaneously what the audience sees, what audio is doing, what is on the screen, and who is speaking next.

Two documents that look alike and do opposite jobs

An agenda answers a question the audience has: what am I here for, and when can I get coffee. It is a public artifact, written in blocks, and its job is to set expectations.

A run-of-show answers a question only the crew has: what am I doing right now, and what happens in sixty seconds. It is a private artifact, written in minutes, and its job is to remove decisions from a moment when there is no time to make them.

Small events conflate the two constantly, and the reason is understandable: for a twelve-person meetup, the agenda genuinely is the run-of-show, because one person is doing everything and holds the whole thing in their head. The conflation stops working at precisely the moment a second person is involved in delivery.

The moment two people are responsible for the same evening, the agenda stops being enough - because an agenda never says who.

That threshold arrives earlier than most organisers expect. A speaker plus a host is already two people. Add someone handling the door and someone running slides and you have four humans whose actions have to interlock, coordinated by a document that only lists topics and times.

What a real run-of-show looks like at the minute level

It is worth seeing the granularity, because it is much finer than most people imagine, and the fineness is the entire point.

A published production timeline from a real conference, documented by the team at Centric Events, breaks the opening of a single morning into countdown blocks measured to the minute: an 8:30 AM entry with a ten-minute buffer, 8:45 with a fifteen-minute buffer, 8:59 with a one-minute buffer before the opening video rolls. Each row specifies which microphone number is live, what state the lighting is in, what is on the main screen, and what the confidence monitors are showing the person on stage.

Read that back and notice what it is doing. At 8:59, nobody is deciding anything. The decisions were all made weeks earlier, in a room with coffee, by people who had time to think. What is happening at 8:59 is execution of a script.

Time - What the agenda says - What a run-of-show says

8:30 - - (doors) - Doors open. House lights 60%. Walk-in music at −20dB. Registration: 5 staff on desk.

8:45 - - - 15-min call to stage. Mic 1 checked and muted. Speaker in position offstage left.

8:59 - - - 1-min call. House to 20%. Screen to holding slide. Confidence monitor to timer.

9:00 - Opening keynote - Video roll. Mic 1 live at video end. Host walks at first applause.

The agenda column is not wrong. It is simply written for someone whose only job is to sit down and watch. Every problem that actually derails a morning lives in the other column.

The twelve-column idea, and why columns beat paragraphs

The core recommendation from that same production write-up is structural rather than a matter of detail: build a master timeline with a column per department, rather than a sequential list of instructions.

The reason is about how the document gets read under pressure. A crew member during a live event does not read the run-of-show front to back. They find the current time and read across. A columnar layout makes that a one-second operation; a paragraph layout makes it a search.

The exact column set depends on the event, but the principle is that every function which can act independently gets its own lane, so that one row is a complete cross-section of a single moment.

  • Clock time and duration - the two anchors everything else hangs from.
  • Audience-facing content - what is happening on stage or in the room.
  • Audio - which microphone is live, which is muted, playback state.
  • Video and screens - main screen content, confidence monitor content.
  • Lighting - house level, stage state.
  • People - who is on, who is next, who is walking where.
  • Owner - the single named human responsible for the row happening.
  • Notes - the contingency, the thing that went wrong last time.

A small event does not need twelve columns. It might need four. But it needs them as columns, and it needs the owner column most of all, because that is the one that turns a description into an assignment.

A run-of-show without an owner column is just a more detailed agenda. The names are the document.

Buffers are content, not slack

The most instructive detail in a professional timeline is that the buffers are written down as named rows, with their own durations, rather than existing as unstated hope in the gaps between items.

An agenda that says a keynote runs 9:00 to 9:45 and a panel runs 9:45 to 10:30 has quietly asserted that a speaker will finish to the second and that four panelists will seat themselves and be miked in zero minutes. Neither of those has ever happened.

A run-of-show handles it by making the transition an item. The panel does not start at 9:45; the panel changeover starts at 9:45, runs four minutes, has an owner, and specifies that mics 3 through 6 go live as each panelist sits. The panel starts at 9:49. Nothing has been lost - the time was always going to be spent. It has simply been moved from the invisible column into the visible one.

This is also the mechanism by which events recover. When a keynote overruns by six minutes, an agenda offers no guidance and the rest of the day silently slides. A timeline with named buffers tells the person running the clock exactly which two rows can absorb it and which one cannot.

The handoff problem, which is the real problem

If you audit what actually goes wrong at small and mid-sized events, very little of it is content failure. Speakers are usually fine. Panels are usually fine. What fails is the seam.

  • The microphone that was not live. Somebody muted it after the last speaker and nobody was assigned to unmute it for the next one.
  • The slide deck that was not loaded. The presenter arrived with a laptop nobody planned for and the changeover took four minutes of visible silence.
  • The speaker who was in the bathroom. Nobody owned the job of physically locating the next person during the preceding item.
  • The lights that stayed at full. The video played on a washed-out screen because a lighting cue existed in someone's intention rather than in a document.
  • The break that did not end. No named human owned the job of getting people back in the room, so the second half started eleven minutes late.

Every one of those is a run-of-show failure, and none of them are visible on an agenda, because an agenda has no vocabulary for them. They live in the transitions, and transitions are exactly what the columnar format forces you to write down.

How to build one without production experience

The intimidating version of this document belongs to a conference with a technical crew. The useful version for a fifty-person event fits on two pages and takes about ninety minutes to write.

  • Write the agenda first, honestly. Blocks and times, the version the audience sees. This is your skeleton, not your plan.
  • Insert a row between every pair of items. Every single one. Name it - "panel changeover", "break return", "speaker two setup" - and give it a real duration, not zero.
  • Add columns for whatever can act independently. For most small events that means audio, screen, people, and owner. Four columns is a real run-of-show.
  • Put a name in the owner column for every row, including the boring ones. If a row has no owner, it will not happen, and you have just found a gap while it is still cheap to find.
  • Walk it out loud with the people named in it. Reading it aloud is where you discover that two rows assign the same person to two places, which is the most common defect in a first draft.
  • Mark the rows that can absorb overrun. Two or three is enough. This is what turns a fixed schedule into a recoverable one.

The out-loud walkthrough is the step people skip and the step that finds the most defects. A document that reads fine silently frequently falls apart the moment someone says "wait, I'm at the door at that point."

Who should hold the clock

One structural decision matters more than the document's format: somebody who is not hosting must own the timeline.

The host cannot do it. A host is on stage, in conversation, reading a room, and is the single worst-positioned person to notice that the schedule is six minutes down and the next buffer is in twenty minutes. Asking the host to also run the clock is asking one person to be both inside and outside the event simultaneously.

This is the same failure that shows up in group organising generally, where one person quietly becomes the missing database because no system was holding the state. In production, the equivalent is one person becoming the missing clock - and the fix is the same, which is to give the state an address outside anyone's head.

Role - Owns - Cannot also own

Host / MC - The room's attention - The clock, the cues, the door

Timeline owner - Clock, cue calls, buffer decisions - Anything requiring them to leave the room

Tech - Audio, screens, playback - Locating people

Floor - Speakers, doors, break returns - Anything at a fixed position

At a fifty-person event these can be three people rather than four, and at a twenty-person one they can be two. What they cannot be is one, which is the arrangement most small events default into without ever deciding to.

Three questions before your next event

  • Does every transition in your schedule have a duration and a name? If transitions are implied rather than written, your schedule is a wish rather than a plan.
  • Is there a named human for every row, including breaks? Rows without owners are the rows that fail, and you can find them all in ten minutes.
  • Who is watching the clock, and are they also on stage? If those are the same person, the event has no clock.

What to take from this

An agenda is a promise to your audience about content. A run-of-show is a set of instructions to your team about seams. Almost everything that goes visibly wrong at an event happens in a seam, which means the document most organisers skip is the one aimed directly at their actual failure mode.

You do not need a production background to build one. You need to take the agenda you already have, insert a row for every gap, add a column for every person, and put a name in every cell of that column. The first time you do it you will find three rows nobody owns, and finding them on a Tuesday afternoon is considerably cheaper than finding them at 8:59.

Frequently asked questions

What is the difference between an agenda and a run-of-show?

An agenda is audience-facing and organised in content blocks - a keynote at nine, a panel at ten. A run-of-show is crew-facing, organised in minutes, and assigns a named person to every cue and transition between those blocks.

Does a small event really need a run-of-show?

Once more than one person is responsible for delivery, yes. A speaker plus a host is already two people, and the failures that derail small events are almost always handoffs between people rather than problems with the content itself.

How detailed should the timeline be?

Professional productions go to the minute, and sometimes tighter around openings - published examples include entries at 8:59 with a one-minute buffer. A fifty-person event can work at five-minute granularity as long as every transition has its own row.

Why should transitions be written as separate rows?

Because a schedule that runs one item straight into the next has silently assumed that changeovers take zero minutes. Making the transition a named row with a duration moves that time from an invisible assumption into a visible plan.

What columns should a run-of-show have?

At minimum: time, what the audience sees, audio state, screen state, and an owner. The owner column matters most, because it is what turns a description of the event into an assignment of responsibility.

Who should keep track of time during the event?

Someone who is not hosting. A host is inside the room's attention and is the worst-positioned person to notice the schedule has slipped, so the clock needs to belong to someone whose only job is watching it.

How do you recover when a session runs long?

By marking in advance which rows can absorb overrun. A timeline with two or three designated flexible buffers gives the person on the clock an immediate answer, where an agenda offers no guidance and the whole day slides.

What is the most common mistake in a first run-of-show?

Assigning the same person to two places at the same time. It is nearly invisible on paper and nearly always caught the first time the document is read aloud with the people named in it.

Ontaym Editorial Team

Ontaym builds tools for organising real-world gatherings, so the team spends its days on the coordination problems this article describes. Articles are researched against primary sources, reviewed before publication, and revised when the underlying facts change rather than on a schedule.

Keep the plan in one place your whole team can read.