Multi-track industry summits
Choosing which sessions should run at the same time
Your summit has more good sessions than time slots, and every pairing means some delegates will miss something they wanted.
Opens WhatsApp with a draft you can edit before sending. Nothing is sent automatically.
The short answer
Run two sessions at the same time only when they serve different delegates, use different speakers and are unlikely to be wanted by the same person. Sessions that your core audience would attend both of belong in separate slots, or in the plenary.
Score each pair on audience overlap, speaker conflict and expected demand before locking the grid. A clash you chose with a reason is far easier to defend than one you found after the programme was published.
What parallel sessions actually cost the delegate
Every parallel slot forces a choice. A delegate who wanted both sessions leaves with half of what they came for, and members notice when the same clash recurs year after year.
The aim is not zero clashes, which is impossible, but clashes that land on people who can send a colleague, read the slides or catch a repeat.
Four tests for any pair of sessions
| Test | Question to ask | If the answer is yes |
|---|---|---|
| Audience overlap | Would the same job role or member group want both? | Move one to another slot, or pair each with a session for a different group. |
| Speaker conflict | Does any speaker, moderator or panellist appear in both? | Separate them; see planning shared speakers for the exceptions. |
| Demand imbalance | Is one session likely to fill its room while the other stays thin? | Pair the popular one with a smaller specialist one, or plan the larger room for it. |
| Content echo | Do both cover the same ground from different angles? | Merge, re-angle or separate them; see preventing repeated content. |
A sequence for building the grid
- List every confirmed and provisional session with its intended audience, speakers and format (talk, panel, workshop).
- Mark the sessions your core audience must not miss and keep each of those alone in its slot or in the plenary.
- Group the remaining sessions by audience and place sessions for different groups side by side.
- Check each pair against the four tests and write down the reason for any clash you accept.
- Run the draft grid through the multi-room allocation checker to catch double-booked speakers and room clashes before the grid is shared.
- Ask two or three people from different member groups to read the grid as a delegate and tell you what they would have to give up.
Who decides
The programme chair or committee owns the pairing decision. The secretariat or project lead prepares the options and records the reasons.
Speakers should not choose their own slot against another speaker's. Offer constraints (travel, other sessions) and let the programme owner place them.
Common mistakes
- Pairing two sessions for the same job role because the topics look different on paper.
- Placing the sponsor-supported session against the headline session, then facing complaints from both.
- Treating a thin track as filler and putting it opposite the strongest one.
- Fixing the grid before speaker availability is confirmed in writing.
- Forgetting that a workshop with limited seats and a talk with open seating behave differently when paired.
Worked example · Fictional example
A fictional logistics summit grid
Fictional organisation and figures, for illustration only.
Persatuan Fiktif Logistik Malaysia plans a two-day summit with three parallel tracks: ports and customs, warehousing, and digital freight. About 450 delegates are expected, and registration data from last year shows most customs brokers also came to the ports sessions.
The first grid put the ports keynote against the customs update. The committee scored the pair as high overlap and moved the customs update to the afternoon, opposite a warehouse automation session aimed at a different group. One accepted clash remains: a digital freight panel against a warehousing case session, noted as 'accepted: slides shared after the event'.
Use this yourself
Session pairing worksheet
Copy this table. Fill one row for each pair that shares a time slot, and write a reason beside every pair you keep.
| Slot | Session A | Session B | Audience overlap (H/M/L) | Shared speaker? | Demand expectation | Decision and reason |
|---|---|---|---|---|---|---|
Handle it in-house, or bring in help?
Your team can usually handle this when
- The summit has two tracks and a stable audience you know well.
- One programme owner can make the call and record it.
- Speakers are confirmed and nobody appears twice.
Outside planning help earns its fee when
- Three or more tracks with speakers moving between them.
- Several committee members each want their own topic in the best slot.
- The grid keeps changing and the secretariat cannot keep every document consistent.
Need the grid checked and kept consistent?
A conference project lead can score session pairs with your programme committee, run the grid through the allocation checker, record each accepted clash and keep the room, speaker and printed programme versions aligned. Programme choices stay with your committee. Send the draft session list and the number of rooms you expect to use.
Questions organisers ask
How many sessions can run in parallel?
That depends on audience size, room availability and how well the sessions are spread across member groups. Start from the number of distinct audiences, not the number of rooms the venue has.
Should the most popular session go opposite a weak one?
Usually not. It sends the wrong signal to the weaker session's speaker and often leaves an empty room. Pair a popular session with a specialist one that serves a different group.
Can speakers pick their own slot?
They can state constraints. The programme owner places them, so the grid stays balanced across the whole programme.
What if two accepted clashes hit the same group?
Offer that group a recording, slides or a repeat session if the format allows. Ask the venue and AV supplier whether recording and repeats are practical.
Related resources
Content record: Draft. Written from the cited sources and checked by automated rules; not yet independently reviewed.