QR check-in works beautifully right up until it does not, and when it fails it usually fails in the same handful of ways. The good news is that almost none of these failures are mysterious. They are predictable, they have known causes, and most can be designed out before the door ever opens. A team that has met each one in advance handles it in seconds. A team meeting it for the first time, in front of a growing queue, does not.
Here are the failures that actually happen at a busy door, and the habit that prevents each.
The screen too dim to scan
The single most common scanning problem has nothing to do with the code and everything to do with the phone displaying it. A guest pulls up their pass on a screen set to minimum brightness, the scanner cannot read it, and the lane stalls while they fumble through settings.
The fix is partly the guest's and partly yours. A confirmation email that reminds people to turn their brightness up helps. But the more reliable fix is a scanner that copes with a dim screen, and a door team trained to say "turn your brightness up" before anyone starts troubleshooting. It is the first thing to try and it solves most cases instantly. Bright sunlight causes the mirror-image version of this problem, where the screen is fine but glare defeats the scanner. Scanning in bright sun and low light covers both ends.
The screenshot that should not work
People screenshot their passes, forward them to friends, and sometimes try to use a code that belongs to someone else. A QR check-in that simply reads "is this a valid code" cannot tell the difference. That is a security hole, not a feature.
The answer is a signed pass that the system can verify as genuine and can mark as already used. When a code is scanned, the system checks it is authentic and not a duplicate of one already through the door. A forwarded screenshot of an already-used pass gets flagged, not waved in. Why a signed QR pass beats a screenshot explains how that verification works and why a plain code is not enough.
A QR code that anyone can copy and reuse is a ticket to nowhere. The value is in the pass being verifiable and single-use, not just scannable.
The double scan and the missing record
Two related problems sit at the heart of a busy door. The double scan, where the same person is checked in twice because a staff member was not sure the first scan registered, and the missing record, where someone is sure they scanned but no entry appears. Both come from the same root: a scan that does not give clear, immediate feedback.
A good scan tells the operator instantly and unambiguously what happened: checked in, already checked in, or not recognised. With that feedback there is no temptation to scan again "just in case", and no confusion about whether it worked. Without it, the door fills with uncertainty, which is slower and less accurate than honest failure. What happens in the moment a code is scanned walks through the split second that decides this.
The connection that drops mid-rush
Venue wifi has a way of failing exactly when the door is busiest. If your scanning depends on a live connection for every single scan, a network wobble becomes a queue. This is not a rare edge case. It is one of the most common live failures at events, and it is entirely foreseeable.
The defence is a system that keeps scanning when the connection drops and syncs once it returns, so a network blip is invisible to guests. Confirm this works during your pre-doors checks rather than discovering it during the rush. Scanning attendees when the venue wifi drops covers what resilient behaviour should look like.
A short field guide
When something does go wrong, a calm sequence beats panic. Train the door team on this order:
- Dim screen. Ask the guest to raise their brightness before anything else.
- Glare. Tilt the phone or shade it with a hand.
- Not recognised. Fall back to a name search on the same device, do not reach for paper.
- Already checked in. Check whether it is a genuine duplicate or a re-entry, then decide.
- No response from the device. Switch to the charged spare and keep the lane moving.
Notice that none of these involve apologising to a backed-up queue, because each is handled in seconds by someone who expected it. The whole point of meeting these failures in advance is that they stop being incidents and become routine.
Designing the problems out
The deeper lesson is that most QR check-in trouble is decided before the day, in the choices about passes, scanners and fallback. A signed, single-use pass removes the fraud problem. A scanner with clear feedback removes the double-scan problem. Offline-capable scanning removes the network problem. A trained team removes the panic. Get those four right and the average check-in stays close to eight seconds even when something minor goes wrong, because nothing minor is allowed to stall the lane.
QR check-in is not fragile. Done carelessly it has a handful of sharp edges, and done thoughtfully those edges are simply gone. The events that have smooth doors are not lucky. They met every one of these failures in a planning meeting, decided how to handle it, and briefed the team so that on the day there was nothing left to be surprised by.
