The agenda is not just for attendees
Most tools treat the agenda as a publishing artefact. Structure it properly and it becomes the foundation for production, speaker preparation, locations and every live change that follows.
The agenda as an artefact
Ask most event software what the agenda is for and the answer is: showing attendees what is on. That is true, and it is about a fifth of the job.
Treated as a publishing artefact, the agenda is a list of titles and times that gets exported to a website and an app. It is the last thing built and the first thing to go stale, because nothing else depends on it — it is downstream of everything and upstream of nothing.
What a structured agenda holds
A session is not a row of text. It is a set of relationships, and if you model them the agenda stops being a list and starts being the event.
- Time and duration
- Not just a start — a length, so a change recalculates what follows.
- Place
- A real location in the estate: building, floor, room, stage. Not a room name in a text field.
- People
- Speakers as records, so a change to a person reaches every session they are in.
- Track
- What this runs alongside, which is what makes a clash detectable rather than discoverable.
- State
- Draft, confirmed, published — so the programme can keep moving without moving in public.
Everything downstream
Once a session holds its relationships, five other surfaces come free. Not "can be exported to" — come free, because they are reads of the same record.
The portal shows attendees what is on and where. The speaker page answers a speaker’s four questions. The showflow inherits the running order and adds cues. The prompter knows which session it is in. The signage outside a room knows what is in that room next.
When something moves
This is where the structure earns its keep. A flat agenda handles a change by making you find every consequence yourself. A structured one knows what the consequences are.
Move a session by twenty minutes and the questions are immediate and mechanical: what else is in that room, who is speaking in both, does this now clash with the thing on the other track, does the turnaround still fit, which published surfaces need to catch up. Those are answerable from the model. They are not answerable from a list of titles.
How to build one that survives
Three habits, learned the hard way.
Put the real estate in early, even when it is provisional — "Room TBC" as a location is fine; "Room TBC" as free text in a title is not. Give every session a duration rather than an end time, so moving one thing recalculates instead of overlapping. And keep draft and published genuinely separate, so that planning out loud never costs you a public correction.
The showflow piece picks up where this leaves off — what happens once the programme is right and you have to actually run it.
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.