How to set up a QR code entry system
A volunteer searching a paper list spends 20-30 seconds per person; at a 200-person event that means a delayed programme. QR check-in brings the same job down to seconds and records attendance for you. Here is how it works and what to watch when setting it up.
How QR check-in works
A QR code is a square barcode with a short piece of text inside it. At an event entrance that text is usually a unique key pointing to the attendee's registration. The process has three steps:
- Issue: when someone registers, the system generates a code specific to them and emails it. The code belongs to the attendee, not to the event.
- Scan: a volunteer at the door scans it with their phone camera. The scanner sends the key inside the code to the server.
- Verify: the server checks whether the registration is valid and whether it has already been used, then shows the result: valid, duplicate or invalid.
The third step is the critical one. If verification does not happen on the server, the system is only QR-shaped — the code scans, a name appears, and nobody notices the same code being used twice. What makes a QR system useful is not the barcode but the verification behind it.
Setup in four steps
Get registration working first
A QR code is tied to a registration record, so you need an online form first. No registration means no code to hand out.
Automate code delivery
The code should go out with the confirmation. Codes sent by hand arrive late and someone always gets missed.
Walk volunteers through the scanner
Do a two-minute dry run beforehand: let each volunteer open the scanner on their own phone and scan a test code. The door is the most expensive place to try something for the first time.
Agree a fallback
Decide in advance how to handle someone who cannot find their code, and what happens if connectivity drops.
What hardware you need
A common misconception is that QR check-in requires a dedicated handheld scanner. For events, it almost never does.
- Volunteer side: any smartphone with a camera. A scanner screen that opens in the browser is enough — no app installation needed.
- Attendee side: the email or registration page on their phone. Low screen brightness slows scanning down, so "turn your brightness up" is a genuinely useful thing to say at the door.
- Printed codes: for attendees without a phone, the same code printed on paper scans identically.
Handheld scanners only make sense for very high-volume gates where seconds matter. For events of a few hundred people, phones are practically faster because several volunteers can scan in parallel.
Practical rules at the door
Even a correctly built system queues up if the door is badly organised. Three rules make a visible difference:
Split the two flows
Pre-registered attendees and walk-ins should not share a queue. Walk-in registration always takes longer and holds everyone behind it.
Keep a live counter open
Seeing how many people are inside lets you fix catering and seating decisions during the event rather than after it.
Keep permissions narrow
A volunteer with scanner access should not see the full attendee list. All the door needs is one answer: valid or not?
Security: forged and duplicate codes
Two questions come up more than any others: what if someone forwards their code to a friend, and can a code be forged?
Duplicate entry
A second scan of the same code must be blocked on the server. In a correctly built system the volunteer sees "this code has already been used" along with the time of the first entry. If that check runs in the browser it cannot be trusted — never trust the client.
Forgery
The value inside the code must not be guessable. In a system using sequential numbers (1, 2, 3…) anyone can generate someone else's code. The right approach is an unguessable value that the server actually verifies — checking that the format looks right is not verification.
Personal data
Do not embed names, phone numbers or email addresses inside the QR code. Codes get photographed off screens; the code should carry only a meaningless key, with personal details staying on the server. This is both the correct privacy posture and the safer one in practice.
What if connectivity drops?
This is the most legitimate concern teams raise. If the venue is a basement or mobile coverage is weak, verification cannot run. A three-layer plan removes the risk in practice:
- Primary: the venue's wireless network. Test it at the door before the event — a signal that works mid-room may not reach the entrance.
- Secondary: a volunteer's mobile hotspot, which the door devices connect to.
- Last resort: a copy of the attendee list downloaded on the morning of the event. If connectivity is fully lost, entry runs off the list and attendance is entered afterwards.
The important detail about the third layer: the backup list must be taken the morning of the event. A list downloaded a week earlier will not contain anyone who registered since.
At a 200-person event that difference is roughly 80 minutes at a single door. The bigger win is that attendance records itself — there is no post-event data entry left to do.
Frequently asked questions
Do I need to buy special hardware to scan QR codes?
No. Any smartphone with a camera works; the scanner opens in the browser with no app to install. Handheld scanners only make sense at gates handling thousands of people.
What if an attendee loses their QR code?
The code is tied to their registration rather than being a one-off ticket, so it can be resent by email or retrieved from the attendee portal. Searching by name at the door is always available as a fallback.
Can two people use the same QR code?
Not in a correctly built system: the second scan is blocked on the server and the volunteer sees a "already used" warning with the time of the first entry. If that check runs client-side, the system cannot be trusted.
Does the QR code contain the attendee's details?
It should not. The code should carry only an unguessable key pointing at the registration, with name, phone and email staying on the server. Since codes can be photographed off a screen, embedding personal data is an unnecessary risk.
How should we handle walk-in registrations?
Give them a separate lane. Walk-in registration always takes longer, and putting them in the same queue as pre-registered attendees slows both groups down.