// INSIGHTS
Running Two Competing Delegate Programmes in One App
5 min read
Some conferences run two programmes at the same time on purpose. Two tracks, two delegate groups, two leaderboards, sometimes two sponsor sets, competing for the same attention in the same building. We have built this for conferences of 250 delegates and above. It is not two apps. It is one app with a cohort model, and the cohort model has to go in before anything else does.
One binary, two realities
Cohort has to be a first-class field on every content object from the first line of schema design. Sessions, speakers, sponsors, notifications, quizzes, leaderboards, documents, floor plans. Each one carries a visibility value of cohort A, cohort B, or shared. Retrofitting that after the fact means touching every query, every screen and every cache key in the application, and it doubles the QA matrix at exactly the point in the project where you have no time.
The interesting design work is deciding what is shared. Opening plenary, keynotes, lunch and the awards dinner are almost always shared. Breakout sessions, workshop bookings and the points economy are almost always split. Notifications are the subtle one, because an operational message about a bus departure is shared while a message about a session starting in ten minutes is not, and sending the second one to the wrong cohort is the fastest way to make people mute the app.
Then there are the people who sit in both. Organisers, speakers, press, sponsor staff and the AV team all need to see everything, and a delegate occasionally needs to move between cohorts mid-event because registration put them in the wrong one. That means multi-cohort membership rather than a single field, a cohort switcher in the interface for those roles, and an admin tool that can move a delegate and carry their agenda and their points across with them.
The cohort model in three numbers
What the app has to hold
Cohort-scoped agenda
Each delegate sees their own programme with shared plenaries merged into the correct time slots. Nobody scrolls past forty sessions they cannot attend.
Parallel points economies
Separate leaderboards, separate prize pools and separate scoring rules if the two programmes have different shapes. A workshop track and a lecture track cannot share a scoring formula fairly.
Targeted push channels
Every send picks a cohort or explicitly marks itself shared, and the console makes that choice unavoidable. Defaulting to everyone is how the wrong message reaches the wrong hall.
Cohort-aware reporting
Attendance, feedback and sponsor scans reported per cohort and combined. Organisers running competing programmes want to know which one worked, and a merged number cannot tell them.
Setting it up without a rebuild
Tag the delegate list first
Cohort assignment happens at registration and arrives in the export. Assigning cohorts after login, based on what people click, never converges.
Model shared items explicitly
Go through the agenda and mark every item as A, B or shared before build starts. The ambiguous ones always turn out to be a programme decision, not a technical one.
Test with four accounts
One from each cohort, one dual-role and one freshly moved between cohorts. Most cohort bugs only appear on the fourth account.
Brief the help desk
The desk needs to see which cohort a delegate is in and move them in one action. That single tool prevents the majority of day-one escalations.
What usually goes wrong
Cohorts added late are the recurring disaster. A build that assumed one audience needs a filter on every query, a cohort dimension on every cache key, and a second pass through every screen. The work is not conceptually hard, it is just everywhere, and it lands in the fortnight when you are also loading content and submitting to the app stores. If there is any chance of a second programme, build the cohort field on day one even if it only ever holds one value.
The fairness problem is the one clients underestimate. If cohort A has 150 delegates and cohort B has 400, an absolute-points leaderboard is meaningless, because cohort B will always produce the top scorer. Normalise per capita, or run genuinely separate prize pools with separate thresholds. The same applies to session capacity, sponsor access and even the quality of the rooms. Two programmes competing in one building create real resentment when the rules or the resources differ, and no amount of software design fixes an unfair programme. Say so early, while the agenda can still change.
Common questions
Can one delegate see both programmes?
Yes, if you give them multi-cohort membership and a switcher. It is standard for organisers, speakers, press and sponsor staff. For ordinary delegates it is usually a programme decision rather than a technical one, and most organisers keep the split strict so the competition stays meaningful.
Does two programmes mean twice the cost?
No, provided the cohort model is designed in from the start. The additional cost is mostly in content management, testing and the extra reporting views, which typically adds a modest percentage rather than doubling anything. Adding cohorts to a finished single-audience app is where the cost genuinely escalates.
What if the split is by language rather than by track?
The mechanics are identical. A Hindi programme and an English programme, or Arabic and English at a UAE event, use the same cohort model with content tagged by language instead of by track. The extra work is in translation logistics and in making sure shared sessions carry both language versions of every notification.
Two programmes, one build
Tell us how your programmes split and we will model the cohorts before development starts.
