How do you run many events a year on one registration platform?
By Donghui Qian (Milo)Updated 3 October 20263 min read
Short answer
Standardise what must be identical across events — identity, roles, brand defaults, reporting fields — and leave only the programme and local details unique. One login and one attendee record across the portfolio beats a fresh tool per show; a shared template that nobody can override quietly beats twenty almost-copies.
A team that runs one conference a year can survive a clever one-off build. A team that runs a dozen roadshows, three customer days and a flagship — or a hundred chapter meetings — dies by a thousand almost-identical setups.
This guide is about the registration and on-site stack as a portfolio system. It complements the single-event operations playbook; it does not replace it.
One-off setup cost compounds
Every event needs a form, tickets or registration types, emails, a door process, and a report. If each of those is invented again, you pay four times:
- Calendar time — weeks of rebuild before every show.
- Training time — staff learn a slightly different admin each time.
- Data time — exports that do not share field names cannot roll up.
- Risk time — the mistake you fixed in March returns in September under a new clone.
Standardise the spine; localise the skin
| Keep identical across events | Allow to differ per event |
|---|---|
| How a person is identified (email / CRM id) | Event title, dates, venue, agenda |
| Role model: organiser, scanner, exhibitor, finance | Who holds those roles for this show |
| Core registration fields and naming | One-off questions for this programme |
| Email events: confirm, remind, cancel, post-event | Copy, speakers, and local logistics paragraphs |
| Check-in rules and offline behaviour | Number of lanes, badge layout art |
| Reporting definitions (registered, paid, checked-in, no-show) | Targets and commentary for this show’s scorecard |
If “standard” lives only in a Notion page, it is not standard. It has to live in templates the next organiser actually clones.
Account shape: org first, event second
- One organisation account
- Shared billing, shared user directory, shared brand assets. Events hang underneath — they are not separate vendors.
- Attendee continuity
- The same person at spring and autumn events should not require a new identity for your CRM sync to work.
- Permissions by role, not by hero admin
- Chapter leads can edit their event; they cannot rename the company-wide consent field.
- Finance visibility
- Someone can see payouts and refunds across the portfolio without logging into fifteen logins.
Templates that survive contact with reality
- Clone from a golden event, not from last week’s emergency copy.
- Lock fields that feed CRM and legal — marketing consent, sponsor-share, ticket taxonomy.
- Version the template when you change the spine; do not silently edit the clone everyone already forked.
- Retirement path — archive events; do not delete history your finance team still needs.
Roll-up reporting or you are still flying blind
Portfolio teams need answers no single-event export can give:
- Registrations and check-ins across the quarter, by event type and by source.
- Which events convert invite → registration → attendance.
- Where refunds and no-shows cluster.
- Which local teams reinvent forms that break the sync.
If every event uses different field names for “company,” the roll-up will always be a slide deck. Fix naming at the template, not in Excel in December.
Failure modes to refuse on purpose
| Pattern | Why it appears | What to do instead |
|---|---|---|
| New SaaS login per event | A chapter wants freedom | Give them an event under the org with limited roles |
| Duplicate “almost templates” | Nobody wants to touch the golden one | Own a template steward; schedule reviews |
| Personal admin accounts | Fastest way to start | Named roles; offboarding that does not lock the door on event day |
| CRM sync only for the flagship | Integrations feel expensive | Same identity events for every show, or admit regional events are invisible to sales |
How this relates to a single-event playbook
The operations playbook still governs one show from define to close. The portfolio layer decides whether the twentieth show reuses the nineteenth’s spine — or pays full price again. Buy for both jobs: day-of reliability, and cloneable structure.
Frequently asked questions
Usually no. Separate accounts break shared identity, billing, and roll-up reporting. Prefer one organisation with many events, and tight roles for local organisers.
When the second event would otherwise copy-paste the first by hand — often somewhere between a handful of shows and a few dozen chapter meetings. If field names already diverge, you are late.
Identity keys, core registration fields that feed CRM, consent flags, role definitions, and the meaning of registered / paid / checked-in / no-show. Programme and venue details stay local.
The playbook runs one event end to end. This guide is about the system that lets many events share a spine so reporting and CRM sync still make sense.