// INSIGHTS
Registration and Check-In for a 5,000-Delegate Pharma Summit
6 min read
A 5,000-delegate pharma summit does not fail at the keynote. It fails at 08:40 on day one, when 1,800 people arrive inside forty minutes and the registration desk is running a shared spreadsheet on hotel WiFi. Pharma stacks a second problem on top of the first. Every scan has to hold up to a compliance review eighteen months later. Attendance records, HCP categorisation and consent trails matter as much as the length of the queue.
Why a pharma summit is not a generic conference check-in
Most registration systems answer one question: is this person on the list. A pharma summit asks four more. Is this delegate a healthcare professional or a non-HCP. Which sponsor funded their attendance, and does that create a restriction on what they may access. Did they sit in the accredited session long enough to earn the credit hour. And can you produce that evidence later without reopening a spreadsheet nobody trusts.
That changes the data model before it changes the hardware. We build the delegate record with category, sponsor attribution, session entitlements and consent state as first-class fields, not as columns bolted on the week before the event. Every scan writes an immutable event — badge ID, gate ID, device ID, timestamp, operator ID — instead of flipping a boolean on a row. If a record is disputed, you replay the events rather than argue about the current state.
- HCP and non-HCP separation drives badge colour, zone rights and reporting splits from a single source field
- Session-level attendance uses entry and exit scans, so credit hours are calculated from dwell time rather than asserted by a form
- Consent captured at registration under the DPDP Act, with the purpose written in plain language and a stored timestamp
- Sponsor scoping so a sponsor's dashboard shows their delegates and nothing else
The queue is the visible problem. The audit trail is the expensive one.
The numbers we design against
What sits inside the check-in stack
Offline-first scanning devices
Each handheld carries the full delegate manifest and writes scans to local storage. Network loss slows nothing down; it only delays reconciliation.
Deterministic duplicate handling
A badge scanned twice at the same gate inside a set window is recorded once and flagged, not counted twice. Session dwell calculations stay clean.
Category-aware badge design
Badge colour, zone icons and printed entitlements are driven by the delegate category field, so a mis-set category is visible to a human on the floor.
Live desk dashboard
Arrivals per minute, queue depth per lane, printer status and device battery on one screen, so the floor manager reassigns staff before a queue forms.
How the build runs, week by week
Data model and consent language first
We agree the delegate categories, entitlement rules and DPDP consent wording before a single screen is designed. Changing this later is what breaks timelines.
Registration site and WhatsApp confirmation
Delegates register, receive a QR badge on WhatsApp and can update details themselves. SMS fallback runs on DLT-registered templates.
Load test at four times peak
We simulate the real arrival curve, not an average. If 40 percent of the room arrives inside the first hour, that is the load profile we test.
Dry run on site with real hardware
Full lane setup the evening before, including a deliberate WiFi kill to prove the offline path and the reconciliation report.
What usually goes wrong
The most common failure is not technical. It is a delegate list that arrives at 22:00 the night before, in three files, with the same person present in all three under different spellings and two phone numbers. Deduplication then happens live at the desk, by a volunteer, under pressure. We treat phone number as the primary identity key and run fuzzy matching in advance, but if the list lands twelve hours before doors open, some of that cleanup will happen in public.
The second failure is venue WiFi. Hotel and convention centre networks in India are frequently sold on peak capacity that assumes browsing, not 60 devices holding persistent connections. We plan for the network to die, because sometimes it does. What we cannot fully absorb is a power situation with no UPS on the registration desk — printers lose their spool, and a badge that was printing when the power cut has to be reprinted. Ask for dedicated circuits and battery backup in the venue contract, not on the day.
The third is scope. Someone will ask for a lucky draw, a photo booth and a feedback survey on the same devices doing check-in. Each addition costs seconds per delegate. At 5,000 delegates, three extra seconds is over four hours of aggregate queue.
Questions organisers ask us
How many lanes do we need for 5,000 delegates?
It depends on the arrival curve, not the headcount. If 1,800 people arrive in the first forty minutes, you need to clear roughly 45 delegates per minute. At 12 to 15 seconds per delegate for a scan-and-collect flow, that is 10 to 12 lanes plus two spares. We model this from your invite send-out times and past attendance data before quoting hardware.
Can attendance data be used for CME or credit reporting?
Yes, if you scan entry and exit at the session room and set a minimum dwell threshold. Entry-only scanning cannot prove someone stayed. We export a per-delegate, per-session record with timestamps and the calculated credit hours, which is the format accreditation bodies typically ask for.
Where is delegate data stored?
By default, in Indian data centre regions, with role-based access and a stated retention period agreed with you in writing. Sponsors get scoped views rather than raw exports. We can also deploy on your own cloud account if your compliance team requires it.
Planning a large medical or pharma summit
Send us your expected headcount and invite schedule, and we will model the arrival curve and lane count before you commit to hardware.

