Two guests reach the door with a problem. The first cannot find their pass — the confirmation email is buried, the phone is new, the QR code is simply gone. The second hands over a pass that scans perfectly but belongs to someone who already walked through ten minutes ago. Both need solving in seconds, and the way you solve them decides whether your gate means anything at all.
These are not edge cases. At any event of a few hundred people, someone will lose a pass and someone will forward one, by accident or otherwise. A check-in that has no clean answer for either turns the door into a negotiation, and a negotiation at the door is how queues form and how the wrong people get in.
The lost pass is an identity problem
When a guest cannot present their pass, the real question is not how to make a new code. It is how confident you are that this person is who they say they are. Re-issuing a pass to the right guest is a service. Re-issuing one to the wrong guest is handing out access.
The safe path is to verify against the list, not the pass. The guest is on the guest list under a name and an email. A steward finds them by name, confirms a detail only they should know, and checks them in directly — no new code required, because the scan was never the point. The pass is just a fast way to find a record. If the record can be found another way, the guest is in.
A pass is a shortcut to a name on a list. Lose the shortcut and you fall back to the list, not to a stranger's word.
This is why a guest list that you can search by name in a second is worth more than any clever code. When a steward can find a person without their pass, a lost pass stops being a crisis and becomes a ten-second detour.
The forwarded pass is a reuse problem
The second guest is harder, because their pass is genuine. It was issued to a real invitee. The problem is that the invitee already used it, or shared it, and now two people are trying to enter on one identity.
The defence here is that a pass can only be used once. The first scan checks the guest in. The second scan of the same pass should not silently let a second person through — it should flag that this pass has already been used, and route the situation to a steward who can decide what to do. Maybe the original guest popped out for air and is genuinely returning, in which case re-entry handling covers it. Maybe a screenshot did the rounds, in which case you have caught it.
| Situation | What the scanner should show | What the steward does |
|---|---|---|
| First scan, valid pass | Checked in, all clear | Wave them through |
| Same pass, second scan | Already used, flagged | Verify, decide re-entry or refuse |
| Pass for a name not on the list | Not recognised | Check the list by name |
| Guest with no pass at all | Steward search by name | Verify identity, check in manually |
The point of the table is that each case has a defined answer the steward does not have to invent on the spot. A door where every odd scan is a fresh judgement call is a slow door and an inconsistent one. We have written more on why why a signed qr pass beats a screenshot, and reuse detection is a large part of the reason.
Doing it without breaking the flow
The danger in handling these cases is that you build a second, slower lane for problems and it becomes the lane everyone with any wrinkle joins. The better design keeps the resolution inside the normal flow.
A steward should be able to search the list by name, confirm a guest and check them in from the same device they scan with, in roughly the time a normal scan takes. CheckInHub keeps the average check-in around eight seconds precisely so that the exceptions — the lost pass, the flagged reuse — do not balloon into multi-minute stops. The exception is handled at the front of the queue, not pulled out of it.
Keep a record of what you did
Every re-issue and every flagged reuse is worth logging, lightly. Not for bureaucracy, but because patterns matter. One forwarded pass is a guest being helpful to a friend. Twenty forwarded passes from the same source is a leak, and you want to know about it before next year. A door that quietly records its exceptions gives you that signal. Our note on logging incidents at the door covers how to capture this without slowing anyone down.
The principle underneath all of it
Both problems come back to one idea: the pass is a convenience, and the list is the truth. When you treat the scan as the only gate, a lost pass locks out a real guest and a shared pass lets in a stranger. When you treat the list as the gate and the pass as a fast way to reach it, both problems shrink to something a steward can resolve in seconds.
Build the door so that finding a guest by name is as easy as scanning one, so that a pass can only be spent once, and so that the steward always has a defined next step. Do that and the two guests at the start of this piece — the one who lost their pass and the one who borrowed someone else's — both get the right outcome, fast, without anyone behind them noticing a thing.
