The grid is not the hard part
Laying out a multi-track conference looks like a spreadsheet exercise. Four tracks, six slots, twenty-four sessions, done by lunchtime.
The grid is trivial. What is hard is that a conference schedule is not a schedule for the conference — it is twenty different schedules, one per attendee, and they all have to work simultaneously out of the same grid.
That reframing is the whole job. A delegate does not experience your four parallel tracks. They experience the six sessions they personally chose, the walk between rooms, and whether they got a seat. Optimise the grid and you can still deliver a bad conference. Optimise the paths through it and the grid mostly takes care of itself.
Problem 1: collisions that matter
Every multi-track conference has collisions. Most of them are harmless.
Two sessions running at the same time is only a problem when the same person wants both. Two technical deep-dives in parallel is a genuine collision. A technical deep-dive against a procurement workshop is not, because those are different people.
So the useful exercise is not de-duplicating topics — it is mapping sessions against attendee personas, then checking each time slot for a persona that has two sessions it wants and one that it does not.
In practice, four or five personas is enough: the practitioner, the manager, the buyer, the newcomer, the specialist. Write them across the top of the grid and mark which sessions each would attend. Collisions become visible immediately, and they are almost never where you assumed.
The fix, when you find one, is rarely to cut a session. It is to move it opposite something that persona does not want.
Problem 2: capacity mismatched to demand
The two worst sights at any conference are a queue of people outside a full room, and a well-known speaker addressing a half-empty hall. Both are room-assignment failures, and both are avoidable.
The mistake is assigning rooms by track seniority — the "main" track gets the big room all day — rather than by expected demand per session. Demand does not respect your track structure. A niche technical talk by a well-known engineer will outdraw a generic keynote slot, and an after-lunch session in any track will underdraw everything.
Three signals predict demand reasonably well:
- Speaker profile. Name recognition beats topic almost every time.
- Topic breadth. "Introduction to X" draws more than "Advanced X internals", even at a specialist conference.
- Registration interest, if you collect it. Asking delegates to indicate sessions during registration is cheap and is by far the most reliable input.
Then assign the biggest room to the highest predicted demand in each slot, regardless of track.
Problem 3: transition time
This one is arithmetic, and it is the most commonly botched number in conference scheduling.
Ten minutes between sessions on the same floor. Fifteen when attendees change floor or building. Five minutes — which is what a packed agenda naturally produces — guarantees that every session starts late.
And the delay compounds. A session starting four minutes late finishes four minutes late, which pushes the next transition, and by mid-afternoon the whole grid is fifteen minutes behind with no mechanism to recover. Nobody ever makes time back at a conference. There is no slack in a full day unless you put it there.
| Slot type | Duration | Transition after |
|---|---|---|
| Standard session | 45 min incl. Q&A | 10 min |
| Short talk | 30 min | 10 min |
| Workshop | 60–90 min | 15 min |
| Cross-building move | — | 15 min |
| Mid-morning break | 20–30 min | — |
| Lunch | 60 min minimum | — |
Lunch under an hour does not work at any scale above about eighty people, because the queue is the event.
Build your conference agenda freeThe agenda builder lays out tracks and slots with transition time applied, so a session running long shows you what it pushes rather than leaving you to trace it across a spreadsheet.
Problem 4: the speaker who drops out
Someone will cancel. At a conference of any size, someone always cancels, usually in the final fortnight and occasionally on the morning.
The instinct is to shuffle the grid to close the gap. Do not. By the time a speaker drops out, your agenda is printed, in the app, downloaded to a hundred phones, and screenshotted into a dozen team chats. Moving other sessions to fill a hole invalidates all of it and creates far more confusion than an unfilled slot would.
Instead, keep one or two reserve sessions that can drop into any slot without disturbing anything else: an open roundtable, a panel drawn from speakers already on site, an extended Q&A, or a repeat of whichever session filled to capacity earliest. A repeat is often the most popular option of all, because it rescues everyone who could not get a seat the first time.
Publishing it
Two practical points that conference organizers consistently raise.
The agenda will change after you publish it. Not might — will. Which means a PDF is the wrong primary format: every change leaves stale copies in circulation, and delegates are notoriously reluctant to re-download. A live link that always resolves to the current agenda solves this, with the PDF as a convenience export rather than the source of truth.
Your crew needs a different document. Delegates need the agenda. The AV team, stage managers, and room hosts need a cue-based run sheet with setup times, mic counts, and changeover instructions — a genuinely different artefact, covered in what a run of show is.
For event planners running conferences alongside other formats, the grid structure is worth saving and reusing. Conference-to-conference, the topics change completely and the skeleton barely changes at all.
Worked examples sit in the conference template collection, and for single-track events the run of show builder is the closer fit.