Event Check-In With QR Codes: From Guest List to Door Flow
Your event starts at 7:00 pm. At 6:50 there are 80 people on the pavement, one volunteer holds a clipboard, and the line is not moving. QR check-in fixes this, but only if you make three decisions before doors open, not at the door: which code model to use, who stands at the entrance with what device, and what happens when the network fails.
One code per guest, or one shared code
There are two ways to run QR check-in, and they solve different problems.
Per-guest codes come from pre-registration. Each guest registers in advance, receives a unique code by email, and presents it at the door, where a steward scans it and the system marks that person as arrived. You get accountability: you know exactly who is inside, capacity is enforceable, and a code that was already used gets flagged. The cost is a registration step before the event and a slower door, because guests spend 5 to 15 seconds finding the email in their inbox.
A shared code is the opposite trade. One QR on a sign at the entrance opens a short self-check-in form where guests type their name. Nothing needs to be issued in advance and the door needs no scanner at all. It counts attendance but controls nothing: anyone who photographs the sign can check in from their sofa, and nothing stops a name from being entered twice.
| Per-guest codes | One shared code | |
|---|---|---|
| Setup before the event | Registration form that emails each guest a code | Print one sign |
| At the door | A steward scans every guest | Guests scan and type their name |
| Capacity control | Yes, one code admits one person | None |
| No-show data | Exact | Only who chose to scan |
| Best for | Paid, capacity-limited, invitation-only | Free meetups, open houses, community nights |
If admission has real monetary value, the fraud side matters more than the logistics. How validation rejects a copied or already-used code is covered in the companion post on how QR ticket validation works; this post stays on the door itself.
What the door actually looks like
Forget airport scanner gates. For most events under 500 people, the door is one steward holding a phone.
Throughput is the number to plan around. A practiced steward scans 6 to 10 guests per minute when codes are already open on screens, and roughly half that when guests are still digging through email. For 200 guests arriving in the 20 minutes before start, that is a sustained 10 guests per minute: two stewards, or doors that open 45 minutes earlier, or both.
Small physical details buy real speed. Put a sign 10 meters before the entrance that says "have your code on screen, brightness up", because the inbox search is the slowest part of every scan. Place the scan point in shade or indoors, since glare on a screen regularly forces a second attempt. And keep a printed alphabetical guest list with a marker on a side table; it is the lane for the guest whose battery died in the queue, and it keeps that one problem from stalling everyone behind them.
Walk-ins and plus-ones
Every event gets people who never registered. Decide the policy in the planning meeting, not in front of them at 7:05 pm.
The clean pattern is a second lane. Next to the scan point, a separate sign carries a shared walk-in code that opens a registration form. Walk-ins scan it and register on their own phone while the main line keeps moving, then show the confirmation screen to the steward. If the room has a hard capacity limit, the steward checks the running count before waving them in.
Plus-ones are simpler: the registered guest vouches, the steward adds a +1 next to their name, done. Forcing a full registration on someone standing beside their host gains you one email address and costs you a stalled line.
When the WiFi dies
Venue WiFi fails exactly when 200 phones join it at once, which is check-in time.
Three preparations cover it. The steward's phone runs on mobile data, never on venue WiFi. The guest list gets exported an hour before doors, once as a file on the phone and once on paper, because ticking names with a pen is slow (3 to 4 guests per minute) but cannot crash. And if check-in runs through a hosted page, the steward opens it while the connection is still good and keeps the tab alive.
The shared-code model degrades worst in an outage, because every guest's phone needs a connection, not just the steward's. If your venue is a basement or a field, that alone is a reason to prefer per-guest codes plus an offline list.
What you have after the event
This is the part a clipboard never gives you.
With per-guest codes you get an exact no-show rate. Free events commonly see 30 to 50 percent of registrants stay home, paid events far fewer, and that number sets how much you overbook the next room. You also get the arrival curve: if 70 percent of guests arrived in the final 15 minutes, next time you staff for that surge instead of spreading stewards across two quiet hours.
If the check-in code is dynamic, scan analytics add timing and device data on top. You can build the whole flow, the registration page, per-guest codes and the door link, with QRolling's event QR code generator, and wider setups such as multi-day badges and session tracking are covered in QR codes for events.
Keep the reporting honest, though. A shared code counts scans, not people. Call it "scans at the door" in the recap, not attendance, and nobody gets embarrassed later.
Run the rehearsal
Before the next event, run a five-minute door drill: load five test codes on colleagues' phones, have your steward scan all five, and time it. Divide your expected guest count by that pace, and you have the number of stewards and minutes the real door needs.
