Should you centralise your conference stack, or keep specialist tools?

By Donghui Qian (Milo)Updated 29 October 20266 min read

Short answer

Centralise the path that prints the badge: sell or approve the ticket, issue the QR, check people in at every gate, reprint on demand, and present the same person at the stand. Keep a specialist when it does a job the conference stack should not own — membership, housing, abstracts, venue AV — as long as it consumes that record instead of inventing a second one. If the first hour at the door needs a spreadsheet to join names, you do not have a stack. You have a handoff.

Most large-conference teams already run five tools before anyone is scanned: a site, a registration system, a door or badge app, a stand lead-capture tool, and a spreadsheet that joins them afterwards. Nobody planned that. It accumulated — different budgets, different years, different demos.

This page is a decision, not a slogan. Useful whether or not you buy from us: which jobs must share one person, and which specialists can stay.

Summarise with

The door is the integration test

Procurement debates stay in licences, integrations, and vendor risk. The cost shows up in the first hour, when the queue is already there.

The list is not one list. Sales sold ticket A in system 1; the desk prints from system 2; the stand scans against system 3. The name is right in email and wrong on the badge.
Offline is an afterthought. Venue Wi-Fi drops. One app keeps working; another freezes; staff invent a paper lane.
Reprints become a second product. Wrong title, a companion printed as a speaker, a job change between registration and door day — and the side table is the longest queue.
Exhibitors leave with footfall, not leads they can use. Or with a CSV of scans nobody consented to share in a way legal will accept.

If the stack fails the door, a networking app cannot save the week. Attendees remember the queue. How stacks accumulate is a different question — see why event teams stitch tools.

Centralise the path that prints the badge

Duplicate people, offline failure, and “a scan is not a lead” usually start on the same line:

Sell or approve the ticket.
Issue a QR that is a token, not a mini business card.
Check in at several gates against that same record.
Print or reprint the badge on demand.
Present the same identity at the stand.

That line should be one attendee record. Integrations can copy fields. They rarely copy who owns the exception — bad code, reprint, walk-in — when the queue is already moving.

Keep specialists that do not invent a second badge

Best-of-breed is not the enemy. Using a specialist as a second person database is. Keep the tool that is actually deep where you are heavy; do not let it mint a second identity.

Job	Share the badge-path record	A specialist is fine when
Association membership / AMS	Yes — who may register	It is the source of member status, and registration reads that status instead of re-typing it
Housing, abstracts, venue AV	No	That job is the heavy one, and it does not print a second badge or a second door list
Meeting scheduler the association already standardised	The attendee is the same person	It consumes the record; it does not become the check-in list
Door, reprint, stand identity	Always	Never — a second list here is the failure, however good the app

The rule in one sentence: specialists may sit beside the badge; they should not invent a second one.

A practical test: one list, four jobs

Run this on one upcoming conference, not on a slide. Tick the boxes from the live tools, not from the RFP.

01
Sell or approve tickets
- Same attendee record?
- Who owns exceptions?
- Offline: skip
02
Check-in at several gates
- Same attendee record?
- Works if Wi-Fi dies?
- Who owns exceptions?
03
Print and reprint the badge
- Same attendee record?
- Works if Wi-Fi dies?
- Who owns exceptions?
04
Stand lead capture (consented fields only)
- Same attendee record?
- Works if Wi-Fi dies?
- Who owns exceptions?

If you cannot tick the first column for all four, you do not have a stack problem. You have a handoff problem. “We have an API” is not the same as one person at Gate B matching the person Sales sold.

What usually goes wrong

Buying another module for the first hour. The door did not fail because you lacked a fifth logo.
Treating an integration as ops ownership. Fields can move. Who reprints, who admits a walk-in, and which device holds the list usually cannot.
Counting every stand scan as a lead. A visit without consent is still a visit. It is not a named row legal will let you email.
Assuming two offline devices agree. They cannot see each other. Duplicates show up when they sync — someone has to decide, not a silent merge.

Before the next edition

Map every tool that touches a name between “registered” and “on the floor.”
Mark which ones can invent a second identity.
Pick one gate on opening morning and write the exception path on one page — bad code, reprint, walk-in: who, which device, which list.
Ask exhibitors what they actually export on day two — names they can legally use, or a souvenir CSV.
Only then decide what to centralise for the next edition.

Centralise the badge path. Compromise elsewhere with your eyes open. The question is not whether you will keep some specialists — it is where, and whether the door still works when Wi-Fi does not.

On bagevent

This is how the product is shaped for professional conferences and trade shows. It is not a claim that every specialist job lives here.

One list from site to door. Publish the event site, sell or approve tickets, and check people in against that same record. Phones and desktop desks share live counts while they are online; several gates are first-class, not a bolt-on.
The network will lie. Before doors open, devices download the attendee list. Scanning, search, and check-in keep running offline; check-ins queue with the time they happened and upload when the connection returns. A brand-new walk-in still needs the server — only it can issue a ticket code.
Conflicts are raised, not silently fixed. Two phones can scan the same person while both are offline. When they sync, duplicates are raised for you to decide.
The QR is a token. The code carries an opaque token. Identity lives in the system, not on the code, which is how offline verification and a cleaner privacy story coexist.
Badges are ops. Templates bind to ticket types, so VIP, speaker, and staff are not a desk guess. The desktop client prints at the desk, including offline.
One app, three roles. Door staff check in; stand staff capture consented leads even without signal; attendees carry their badge. Switching roles does not mean switching products.
A visit is not a lead. Without consent the stand sees that a visit happened and that identity was withheld. Exports include only rows the visitor agreed to share.
AI drafts; you confirm. The assistant can draft an on-site run sheet — lanes, staff, power and network asks, volunteer scripts — from a short form. It proposes. You confirm.

Settlement and Stripe sit in the product because organisers need them. They are not the story of the first hour. The story is whether the person at Gate B is the same person Sales sold, Ops printed, and the stand is allowed to remember.

Frequently asked questions

Centralise the path that prints the badge — ticket, QR, every gate, reprint, and the same identity at the stand. Keep specialists for jobs the conference stack should not own, as long as they consume that record instead of inventing a second list.

Selling or approving the ticket, checking in at several gates, printing and reprinting the badge, and capturing consented stand leads. If those four jobs use four lists, the first hour at the door is the integration test you did not schedule.

When it is deep where you are heavy — membership, housing, abstracts, venue AV, a meeting scheduler the association already standardised — and it sits beside the badge instead of minting a second door list.

No. An API can copy fields. It rarely copies who owns a reprint, a walk-in, or the device that holds the list when Wi-Fi drops. Tick the four jobs on a live event, not on an architecture diagram.

No. They cannot see each other while both are disconnected. Each should keep scanning against its downloaded list and queue check-ins with the time they happened. Duplicates are a sync problem for a person to decide, not a silent merge.

Only if the visitor agreed to share those fields. A visit without consent can still be counted as a visit. It should not become a named row in an export legal will not accept.