QR code event check-in: how to run the door at a community event

When someone buys a ticket or RSVPs, the system creates a record for that attendee and a QR code (a square barcode a phone camera can read) that points to it. The code goes out in the confirmation and is often available in the attendee's account too.

At the door, a host scans the code. The system looks up the record, shows the attendee's name and ticket, and marks them as checked in. If the same code is scanned again, the host can see it has already been used. That is the whole mechanism: one code, one person, one scan.

Speed is the obvious reason. Finding "Sam" on a printed list of 150 names, alphabetized by last name, with three Sams on it, takes time. A scan takes a few seconds.

Accuracy is the less obvious one, and it matters more over time. A name list ticked with a pen gives you a rough sense of who came. Scans give you a reliable record of exactly who attended, which you can act on: thank attendees, follow up with no-shows, and learn which events people actually turn up for, not just which ones they sign up for.

Finally, codes protect paid events. A forwarded name is hard to spot. A code that has already been scanned is easy.

Use this formula: scanners needed = people arriving in your busiest 15 minutes ÷ (scans one person can do per minute × 15). A practiced host scanning phones, greeting people and handling the odd problem manages something like 6 to 8 people a minute.

Example: a 200-person meetup where about half the crowd arrives in the 15 minutes before start. That is 100 people in 15 minutes, or about 7 a minute. One scanner at 7 a minute is exactly at capacity, which means any problem (a dead phone, a lost email) creates a queue. Two scanners give you room. Math example, not a customer outcome.

The rule: plan for one scanner more than the arithmetic says, and put the most experienced host on the problem line, not the scanning line.

Most of the delay at any door comes from a small number of people: the ones who cannot find their email, whose phone is dead, or who bought under a different name. Send them to a separate spot with one person, a laptop or tablet, and the full attendee list. Everyone else keeps moving.

Give the problem-line host simple authority: look the person up by name or email, check them in manually, and wave them through. Arguments at the door cost more goodwill than a single unverified guest ever will.

Two days before: send a reminder that tells people to have their ticket ready and where to find it. The day before: charge every scanning device, log in to the check-in screen on each one, and confirm the right event is selected. Download or print the attendee list as a fallback.

Thirty minutes before doors: scan a test ticket (buy one yourself, or use a staff RSVP) to prove the whole loop works on the venue's connection. Check the lighting where people will stand; phone screens are hard to scan in direct sun and in very dim rooms.

At doors: one greeter in front of the line asking people to open their ticket before they reach the scanner, which removes most of the delay. Scanners scan. The problem line handles exceptions. Ten minutes after start, move one scanner inside and keep one at the door for latecomers.

Venue wifi is the most common single point of failure. Test it during setup, and have scanners use their phone's mobile data if it is unreliable. If everything fails, switch to the printed list and tick names by hand, then mark those attendees as checked in later. Nobody should be turned away because of a technical problem.

This is why the printed list is not optional, even if you never use it. It turns a crisis into a minor slowdown.

Within 24 hours, send two different messages. To attendees: thanks, the slides or recording, and the next event. To no-shows: no guilt, just what they missed and the next date. These two groups need different words, which is only possible if you know who is in each.

Over several events, compare RSVPs to check-ins by event type, day and time. If Tuesday evenings consistently turn out better than Saturdays, that is a scheduling decision made for you. If members who attend an event in their first month stay longer, make a first-month event part of onboarding.

HiveLearn events include QR ticket check-in at the door, alongside RSVPs, waitlists, paid tickets with cancellation, automatic reminders and calendar sync. Each attendee's ticket carries a code your hosts scan on arrival, and check-ins are recorded against the same member accounts as the rest of your community, so attendance sits next to course progress and discussion activity rather than in a separate tool.

That connection is where the follow-up work gets easier. Member tags, segments and broadcast email let you message attendees and no-shows differently, and member health scores help you spot members going quiet, for whom an in-person invitation is often the best nudge. See the pricing page for which plan includes events and check-in.

If you only run one large public event a year and have no community around it, a dedicated event tool such as Eventbrite or Luma will do the job well. QR check-in inside the community pays off when events are a regular part of membership.