Venue networks do not fail at random. They fail when the door is busiest, because that is when the most people with the most devices are hanging off the same access point. That is exactly the moment a scanner stops working if it has to ask a server before it can answer.
What "offline" actually has to mean
Plenty of systems call themselves offline-capable and mean that they queue requests and send them later. That does not help at the door: you get no answer about whether the code is valid, so you are guessing.
Usefully offline means three things:
- The guest list is fully on the device before doors.
- Validation happens locally, with an immediate answer.
- The check-in is recorded locally and synced afterwards.
The problem that creates: double scans
As soon as two devices work offline, neither knows who the other just let in. A forwarded code can pass at lane 1 and lane 2.
Only one thing fixes that: the devices have to reconcile with each other the moment any connection exists — a local network with no internet is enough. And when the sync happens, the conflict has to surface rather than being silently overwritten. A double check-in is information, not an error to tidy away.
The test to run before doors
It takes two minutes and almost nobody does it:
- Load the guest list onto every door device
- Turn on flight mode
- Scan a test guest — do you get an immediate answer?
- Scan the same test guest again — is it recognised as already checked in?
- Turn flight mode off — do both scans reach the system?
Step 4 is where most systems fail. A device that cannot spot a double scan offline is worthless on a busy door.
The EventSync scanner preloads the list, validates locally and records check-ins offline. How that fits the rest of your door planning is covered in planning door check-in.