The door: scanning, queues and who can see what

The door is where a ticketing platform is actually judged. Everything before it can be excellent and it will not matter if there is a forty-minute queue in the rain because the scanner cannot reach the internet from a basement in Shoreditch.

Any phone, scoped to one event

Door staff sign in and get a scanner scoped to a single event. They can validate tickets and admit people. They cannot see your revenue, your sales figures, your other events or your customer list.

That scoping is enforced in the security rules rather than by hiding buttons in the interface. The person on the door is frequently a friend, a volunteer, or agency staff you met an hour ago, and the correct assumption is that they will see exactly what the rules permit and nothing else.

It needs a connection today

Validation is checked centrally on every scan, so the scanner needs signal. Offline caching is designed and specified (docs/04 M16) and is not built yet — so if your venue is a basement with no reception, plan for it rather than assume it. This is stated here because discovering it at 20:45 with a queue outside is the worst possible time to learn it.

Override is a first-class outcome

Sometimes the system says no and the answer is still to let the person in. The ticket is on a dead phone; the name is on the guest list nobody synced; the reader is being unreliable. Manual override exists, requires a reason, and is logged with the staff member attached.

A system with no override does not prevent overrides. It produces a member of staff waving people past the scanner entirely, which loses you the record of who came in.

Duplicate scans are shown, not silently rejected

When a ticket has already been scanned, the screen shows when and at which door. That is the information the person on the door needs to make a judgement — a scan ninety seconds ago at the same entrance is a double-tap, and one forty minutes ago at a different door is something else.