What happens when the running order changes five minutes before doors
The change itself takes ten seconds. Propagating it to five documents, three teams and a published programme is what costs the day — and why multi-device sync is not a convenience feature.
The ten-second change
The client comes to you at 08:55. The fireside has to move to after the break, because the person in it is now on a train that is twenty minutes late.
The decision takes ten seconds. It is obviously right and there is nothing to discuss. What follows is the entire problem.
The blast radius
Count what now has to change, at five to doors, while the room fills.
The showflow. The prompter script, because the host’s link into the next item is now wrong. The signage outside the room. The published programme, which several hundred people are looking at on their phones right now. The speaker pack for the person on the train, and for the two people either side of them whose slots just moved. Crew comms, because four departments are holding cues that just renumbered.
Six surfaces, three teams, and about four minutes.
Why screenshots happen
Under that pressure people do a very rational thing, which is to stop using the system and start using a photograph.
Someone screenshots the corrected running order and drops it into the group chat, because that reaches everyone in four seconds and updating six documents does not. It is the correct decision in the moment and it is also the moment the event stops having a source of truth — from here on, some people are working from an image.
What sync has to guarantee
For the change to travel instead of being retyped, three things have to be true, and all three are design decisions rather than infrastructure ones.
- One write
- The change is made once, by whoever is holding the decision, in the place they already are.
- Every read is live
- No surface holds a cached copy that has to be refreshed by a human.
- Nothing surprises
- A change mid-cue must not silently move under the hands of the person calling it.
After the change
The part people forget: the event now has a history, and in three weeks somebody will ask why the fireside ran after the break.
A change that travelled through six documents by hand leaves no usable record of itself. A change made once, in the record, is its own audit trail — what moved, when, and who decided. That is worth having for the debrief, and it is worth a great deal more the one time it becomes a contractual question.
How the sync layer works goes into the specifics of what travels and what deliberately does not.
Plan the event. Publish the programme. Run the show.
One event spine, many views. Build the programme once, then give every person the right live view of it.