Version 14, final, FINAL2
The run sheet for a three-day conference is a forty-page document: build times, rehearsals, session timings, cue points for walk-in music and stings, catering breaks, VIP arrivals, coach departures, contact numbers. It has been through fourteen versions. The one that went to the venue was version eleven. The AV crew printed version twelve. The client's EA has version thirteen, with the CEO's arrival time moved.
On the first morning, the keynote overruns and lunch moves by twenty minutes. The producer tells the stage manager on the radio, the caterer by phone and the coach company by text. The photographer, working from paper, goes to the terrace at the old time. The afternoon break is announced from the stage at a time the caterers were not told.
Why run sheets never stay in step
The run sheet is a document, but an event is a set of timed dependencies. Documents cannot tell people which lines changed or which changes matter to them.
- Every change creates a new file, emailed to a distribution list that is never quite complete.
- People print the version they had, and paper does not update.
- Different roles need different parts, so they make their own extracts, which drift further.
- On-site changes are made by radio and phone, and the document is only updated in the evening, if at all.
- Nobody can see who has seen the latest change.
When crews work from different versions
The failures are small and visible: a VIP met at the wrong entrance, a stage set for the wrong session, a coach waiting outside for an hour, a caterer serving coffee to an empty room. Each one is fixed on the day by your team running around, which is exactly when they should be ahead of the next problem. Clients who stand at the back of the room notice when the event feels reactive rather than controlled.
A live run sheet built from the event plan
- The run sheet is generated from the event plan: each cue or item has a time, a location, an owner and the roles or suppliers involved.
- Everyone on site opens it on their phone through a link, with no app to install, and sees a view filtered for their role: stage, catering, transport, registration, VIP host, client.
- When the producer moves an item, dependent items can move with it, and the change is shown to anyone whose view includes it.
- Changes that affect a role send a short alert, by push or text, stating what moved and to when.
- People acknowledge important changes with one tap, so the producer can see who has seen them.
- A printed version for the stage manager's desk or the venue can be produced at any moment, clearly stamped with the time it was generated.
- The run sheet keeps working on a phone if the signal drops, and catches up when it returns.
| Role | Sees | Gets alerts for |
|---|---|---|
| Stage manager | All stage cues and rehearsals | Session timing changes |
| Catering lead | Breaks, meals, numbers | Break and meal moves |
| Transport lead | Coach and car movements | Departure and pickup changes |
| VIP host | Arrivals, greeters, green room | VIP timings |
| Client | Headline programme | Changes you choose to share |
On site with one version of the day
The keynote overruns. The producer moves lunch by twenty minutes on the tablet, and the afternoon moves with it. The catering lead, the stage manager, the photographer and the coach company each get an alert with the new time. Three acknowledge within a minute; the producer calls the one who has not. The venue's printed copy is regenerated for the green room door. At the evening debrief, the change history shows exactly what moved when, which also helps with supplier invoices for extended hours.
Is your run sheet a file or a system?
- Your run sheet has more than a handful of versions by show day.
- Crew and suppliers print their own extracts.
- On-site changes go out by radio, text and phone calls.
- You cannot see who has seen the latest change.
- Printed run sheets on site show different times for the same item.