The check-in queue is your event's first session. A thousand people will form their first impression of your operation in the ninety seconds it takes them to get through the door — or the twenty-five minutes, if you sized the door on vibes. QR check-in is how you make it ninety seconds, but the QR code is the easy part: the hard parts are arrival math, lane design, and what happens when something breaks at 8:40 a.m.
How QR check-in actually works (60 seconds of theory)
At registration, the system issues each attendee a QR code — done right, it encodes a short opaque token tied to that one registration, not the attendee's personal data. At the door, a scan resolves the token to a registration, marks it attended with a timestamp and operator, and the lane moves on. Three properties separate a real check-in system from a QR generator bolted to a spreadsheet:
- Idempotency. The same badge scanned twice must say already checked in — never create a duplicate, never error out. Duplicate scans aren't an edge case; at a busy door they're a certainty.
- Scoping. A token should only resolve within its own event (and its own organizer's account) — a QR from last year's gala, or a guessed URL, returns not found, and public badge endpoints should be rate-limited so codes can't be enumerated.
- Separation of viewing and attending. Opening or downloading a badge must not mark anyone attended. Check-in is a deliberate act at the door; if merely opening the confirmation email counted, your attendance data would be fiction.
Forwarded emails and screenshots are the abuse case people ask about: the honest answer is that a token identifies a registration, so if two people present the same QR, the second scan flags already checked in and a human applies policy (ID check for restricted events, shrug for a free meetup). What the token model does guarantee is that a photographed badge leaks no phone number or email — which vCard-payload badges do.
The throughput math for a 1,000-person door
Work from the arrival curve backwards. The pattern that repeats across professional events: doors open 60 minutes before the program, and roughly 60% of attendees arrive in the busiest 30–40 minutes — the twenty minutes either side of "I should head in now."
For 1,000 attendees, that's ~600 people in ~35 minutes: a peak arrival rate of ~17 people per minute.
A staffed scanning lane — greet, scan (phone or printed badge), confirm, hand a badge — sustains 4–6 check-ins per minute when it's flowing (vendor-published benchmarks cluster around 200/hour/station, i.e. ~3.3/min, at the conservative end of the same range). Divide 17 by 4.5 and you get 3.8 lanes — and if you open exactly 4, you will still get a queue, because a service system running near 100% utilization queues explosively: any hiccup (a cracked screen, a name change, a lost email) has no slack to absorb it. Size the door to 70–80% utilization:
Lanes = peak arrivals per minute ÷ (lane rate × 0.75) → 17 ÷ (4.5 × 0.75) ≈ 5 lanes, plus a problem desk.
The problem desk is not optional and it is not a lane: it's where the 2–5% of arrivals with anything unusual (no QR, name change, payment question, +1 negotiation) go, so that a four-minute problem never stands in front of forty ninety-second people.
Rules of thumb that fall out of the math:
- One staffed lane per 200–250 expected attendees for a typical 60-minute door with a normal peak.
- Printing at the lane changes everything: an 8-second badge print inside the cycle drops lane rate toward 2–3/min — double the lanes or move printing to a separate pickup point (the badge guide covers the pre-print/on-demand/hybrid decision).
- Self-serve kiosks run slower per unit (amateur users, camera scans, on-the-spot printing) but parallelize cheaply and absorb walk-in registration — pair kiosks for the routine 90% with one staffed desk for exceptions.
Lane design: the queue is a UX problem before it's a math problem
- Split by situation, not alphabet: pre-registered (the fast masses), walk-in / register here, and problem desk. Alphabet splits balance poorly and confuse people carrying two surnames.
- Put a greeter at the queue mouth (one per ~50 people queuing): their whole job is "QR ready, brightness up, screenshots work fine." Thirty seconds of coaching in the queue buys three seconds per scan at the desk — at 600 scans, that's a lane's worth of capacity.
- Signage answers the three questions people actually have: Am I in the right line? What do I need ready? Where do walk-ins go?
- Badge handoff shapes the flow: scan-then-badge at the same station is simplest; for big doors, scan at a line of scanners and collect badges at a separate table just past them — each station does one thing fast.
The failure runbook (print this)
| Failure | First move | Pre-event preparation |
|---|---|---|
| Venue Wi-Fi dies | Keep scanning in offline mode; actions queue locally and sync when the network returns | Choose tooling with real offline support; test it with Wi-Fi off during setup; have a 4G/5G hotspot as bridge |
| Attendee has no QR (lost email, dead phone) | Look them up by mobile number or name at the lane — never send them away to "find the email" | Confirm your check-in tool searches by phone/name offline too |
| Already checked in flag on a scan | Politely verify identity; apply the event's policy (ID for paid/restricted, wave-through for open) | Decide the policy before the event, brief the desk |
| Badge printer jams mid-peak | Route to the reprint station; lanes keep scanning — printing is decoupled from check-in | Spare printer + spare media at the reprint station; test both |
| Queue exceeds ~20 people per lane | Open the flex lane; move a floater to greeter duty; if printing at lanes, switch to badge-later mode | Staff one flex lane; define the trigger number in the morning brief |
| Scanner hardware fails | Fall back to device camera scanning on any phone/tablet | Every staffed device has the check-in screen logged in and tested |
The pattern behind the whole table: decouple the stages (scan ≠ print ≠ solve problems) so any single failure degrades one stage instead of stalling the door.
Offline is a requirement, not a feature
Venue Wi-Fi fails at every third event — usually at 8:40 a.m., under exactly the device load you brought. An offline-capable check-in setup needs four properties, and it's worth verifying each one by pulling the plug during setup, not by reading a brochure: a local cache of the registration list on each device; a durable write queue for check-ins, edits and walk-ins made while offline (surviving a page reload or the device sleeping); ordered, automatic sync when connectivity returns; and idempotent writes, so a check-in that synced twice still counts once. If walk-in registration matters to you, test that specifically — registering someone offline and having them merged cleanly later is the hardest of the four.
How this looks in practice
Novex runs the two-mode pattern this article recommends. The staff check-in screen is the fast lane: plug in USB/Bluetooth keyboard-wedge scanners at any number of desks, and every desk shares one live attended-vs-total progress bar — each scan returns success, already checked in, not found, or error, which is the idempotency and scoping behavior above. The self-service kiosk covers everything else at the door: camera QR scanning, lookup by mobile number, five-field walk-in registration, and on-the-spot transparent badge printing — and it's built offline-first, with a durable local queue that survives reloads, syncs in order when the network returns, and never double-applies a check-in. Every confirmed registration carries a per-registration QR token that only resolves inside its own event, rate-limited at the endpoint, and downloading a badge never marks anyone attended.
Frequently asked questions
How many check-in stations do I need for 1,000 attendees?
Five staffed scanning lanes plus a problem desk, if arrivals follow the normal pattern (~60% inside 35 minutes) and badges are pre-printed or picked up separately. The general formula: peak arrivals per minute ÷ (4.5 scans/min × 0.75 utilization). Printing at the lane roughly doubles the lane count — decouple it.
Do QR check-in systems work offline?
The good ones do, with a local registration cache, a durable queue for offline actions, automatic ordered sync, and idempotent writes. Test by disabling Wi-Fi during setup and running ten check-ins, an edit, and a walk-in — if any of those are lost or doubled after reconnecting, the offline mode is decorative.
What if a guest doesn't have their QR code or their phone is dead?
Look them up at the lane by mobile number or name — the fix takes ten seconds when the tool supports it. Never send people off to dig through email; that's how a lane becomes a bottleneck.
Can a QR ticket be shared or scanned twice?
A properly built system is idempotent: the second scan of the same registration returns *already checked in* rather than admitting a duplicate. What happens next is policy — ID verification at paid events, discretion at open ones. Tokens scoped to one event also mean last year's badge (or a guessed code) simply returns *not found*.
How much faster is QR check-in than manual lists?
A staffed scan lane sustains 4–6 attendees per minute; a name-lookup desk with a printed list or a search box typically manages 1–2, with high variance (spelling, duplicates, "it's under my colleague's name"). The bigger win is variance, not average speed — scans don't have bad days; searches do.
How early should event check-in open?
Sixty minutes before the program for conferences up to ~1,000 people; ninety for bigger doors or heavy badge logistics. Opening earlier flattens the peak arrival rate, which reduces the lanes you need — it's the cheapest capacity you can buy.