Why venues lose signal at exactly the wrong moment
The connection fails for reasons that have nothing to do with your check-in system. Thick walls and underground rooms block mobile signal. Metal-framed marquees and glass facades reflect it. A full room is the hardest case of all: hundreds of phones on the same mobile cell, all opening the same invitation email at once, can slow a connection that tested perfectly an hour earlier. Venue Wi-Fi brings its own surprises — a sign-in page that each device must accept, a password that changed this morning, a network shared with the bar’s card terminals.
The lesson is not to find better Wi-Fi, although that helps. It is to choose a way of checking guests in that does not need a connection to admit a person, and treats the network as something that makes the doors agree faster when it happens to be there.
What “works offline” has to mean
Many tools say they work offline; the phrase covers very different things. Ask what exactly happens when a device loses its connection in the middle of a queue. A check-in that genuinely works without internet does four things on the device itself: it keeps a copy of the guest list, it can read a code and find the guest in that copy, it records the admission locally with the time and the person who scanned, and it sends those admissions when a connection returns.
If any of those four needs the network, the door will stop the moment the signal drops. A tool that only shows a cached page, or that needs a connection to confirm each scan, is not offline check-in; it is online check-in that fails slowly.
- The guest list is held on the device, not fetched for each scan.
- A scan finds the guest in that copy and shows name and status at once.
- Each admission is stored locally with time, door and staff member.
- Stored admissions are sent automatically when the connection returns.
- The screen says clearly that the device is offline, and since when.
Preparing the devices before the doors open
Most offline failures are preparation failures. The phones were not opened on the check-in screen while there was still a connection, so they never received the latest list; or a battery saver closed the app in the background; or a device was handed to a new member of staff ten minutes before opening and has never been signed in.
Prepare every door device as if there will be no signal at all. Sign in, open the event, let the list load completely, and then switch the phone to airplane mode and scan a test code to prove it works without the network. Do this in the venue, at the door, as close to opening time as you can; and do it again after the last change to the guest list.
- Charge every device fully and give each door a power bank and a cable.
- Sign each device in under the name of the person who will use it.
- Load the list on site, after the last edit, and note the time it was loaded.
- Test a scan in airplane mode, then switch the connection back on.
- Turn off battery saver and automatic updates for the evening.
- Clean the camera lens; set the screen bright and the auto-lock long.
Late changes when the doors are offline
A device that is offline knows the list as it was when it last had a connection. A guest added after that moment is not on it; a guest who was uninvited is still on it. This is the one real limit of offline check-in, and it is worth planning around rather than hoping it does not come up.
Freeze the list for routine edits shortly before opening, and route any later change through one person who can tell the doors directly. Give at least one device a reliable connection — a staff phone on a different mobile network, or a dedicated hotspot that guests do not know about — so that late additions can be looked up there. A guest who is not found on an offline device should be sent to that device, not turned away.
Several doors without a connection
With a connection, every door sees every scan within moments. Without one, each device knows only what it has scanned itself. That means two doors can each admit the same code — a guest at the main door, a friend with the screenshot at the side door — and neither will know until they reconnect.
There are practical ways to make this rare. Assign guest groups to doors where it makes sense, so that VIP codes are expected at the VIP door. Keep the doors that are most likely to lose signal close to one that does not. If the venue allows it, run your own small network for the staff devices, so they can reach each other even when the outside internet is down. And accept that a short window of disagreement between doors is the honest cost of keeping the queue moving.
Syncing when the connection returns
When a device reconnects, it should send its stored admissions in the order they happened, and receive the admissions made at other doors in the meantime. The staff should not have to press anything. What they should see is the change: the offline label disappears, a count of admissions sent, and any guest who has now turned out to be admitted elsewhere.
Check the devices once during the evening and once at the end: every device should show that it has nothing left to send. A phone that went into a pocket with twenty admissions still stored is twenty people missing from the report until someone remembers to open it.
Conflicts: when two doors disagree
A conflict is the same guest admitted twice while doors were offline, or a guest admitted offline after their invitation had been withdrawn. The worst thing a system can do is resolve it silently — keep one record, discard the other and say nothing. That hides exactly the event you need to know about.
A sound approach keeps both records, counts the earlier one as the admission, marks the later one as a duplicate, and puts it in front of a person. Most conflicts have a harmless explanation, such as a guest who was scanned at one door and walked round to greet someone at another. Some do not. Either way, the attendance report should count people, not scans, and list the conflicts separately so they can be read.
A paper fallback that does not ruin the report
Keep a printed list at the main door for the worst case: a device that will not start, a dropped phone. Print it as late as possible and write the time on it. If you have to use it, tick names on paper and enter those admissions on a working device as soon as you can, marked as entered from paper. That way the evening’s count still adds up the next morning.
In Winglark, GatePass is built for this: any phone becomes the scanner, holds the list on the device so it keeps working with no signal, and several doors check guests against one list.