Almost everyone arrives at the door with a code on their phone now. In 2024, mobile platforms accounted for close to 59 per cent of all online ticket purchases (Amra and Elma, 2025), and that share keeps climbing. The upside is obvious: no paper, no posting anything, the ticket is always in a pocket. The catch is that a phone screen is a slightly fragile thing to point a scanner at, and once in a while a code will simply refuse to read.
It is worth being calm about this. A code failing to scan is not a system failing. Screens dim to save battery, a cracked protector scatters the laser, someone brightens the photo until it blows out, a wallet pass sits one swipe too deep. None of that is unusual, and none of it should stop the person getting in. The mark of a good front desk is not that a scan never fails. It is that the queue behind never notices when one does.
First, know why a scan fails
Most failures fall into a short list, and knowing which one you are looking at saves fumbling.
The screen is too dark or too bright. A phone on low-power mode dims itself, and a scanner needs contrast to find the pattern. Ask the guest to turn brightness up, or tilt the screen out of a hard overhead light. This clears the majority of them on its own.
The image is degraded. A screenshot that has been forwarded, cropped and compressed loses the crisp edges a reader depends on. This is one of the quieter arguments for issuing a proper pass rather than trusting a screenshot, which we made in full in why a signed QR pass beats a screenshot.
The reader is the weak link, not the code. Bright sun washes out a camera, a wedge scanner needs a steadier hand than a phone does. If several codes fail in a row, suspect the device before the guests. We wrote about matching the reader to the setting in reading any code: phones, tablets and wedge scanners.
The fallback is a name, not a shrug
Here is the part that keeps the door moving. When a code will not read, the crew member does not send the guest away to sort out their phone. They look the person up by name.
A check-in desk worth the name lets you find a guest by typing the first few letters of their name, marking them Checked in, and waving them through, exactly as if the scan had worked. The record is the same, the live count updates the same, the guest is in within a few seconds. The scan is only ever the fast path to the guest record. The name is the reliable one, and it is always there underneath.
This only works if the desk is reading from live data rather than a list someone exported that morning. A guest who registered last night has to be findable, or the fallback fails for exactly the people most likely to need it. That comes down to a clean import in the first place, which we covered in importing a guest list that actually holds up.
When the pass itself is the problem
Sometimes the code reads fine but the pass is wrong: it was cancelled, already used, or belongs to someone else because it was forwarded on. A scanner should tell your crew that plainly rather than just beeping green, so the person on the door knows the difference between a dead screen and a duplicate pass. If a guest has genuinely lost their pass or had it forwarded, reissuing a fresh one on the spot is a two-minute job when the system is built for it, which we walked through in re-issuing a lost or forwarded pass safely. Knowing how the code carries its meaning in the first place helps here too, and we explained that in how QR code tickets actually work.
Plan for the moment the connection drops
The other reason a scan stalls has nothing to do with the code. The venue wifi buckles, the desk goes quiet, and a line forms while a spinner turns. A door that leans on a live connection for every single scan is a door waiting to jam at the worst moment. A signed pass can be verified on the device without a round trip to a server, so the queue keeps moving and the count catches up when the signal returns. We pulled that apart in scanning attendees when the venue wifi drops.
Brief the crew on the fallback before doors open
None of this helps if the person on the scanner freezes the first time it beeps red. Two minutes in the door brief is enough: if a code will not read, ask for brightness, then look them up by name and check them in by hand. Do not send anyone to the back of the queue to fix their phone. That one sentence is the difference between a smooth door and a visible bottleneck, because a stalled guest at the front holds up everyone behind them, not just themselves.
The number to protect is the flow
CheckInHub clears a working scan in about eight seconds, and it has checked in more than 125 000 guests that way. But the figure that matters at the door is not the average scan time, it is the pause when one fails. Keep that pause short and private, and the occasional bad code becomes a non-event: a guest looked up by name, checked in, and welcomed in the same few seconds a scan would have taken. That is the whole job of the front desk, and it is why the fallback matters as much as the fast path. If you want the calm version of the same idea, we described it in the eight second check-in explained.
