Check-in when the venue wifi fails

The venue will tell you the wifi is fine. It is fine. It is fine at two in the afternoon on a Tuesday with eleven people in the building.

At 08:30 on the day, that same network has six hundred phones associating with it, an AV team pushing a live stream out of the main hall, a catering tablet, and a captive portal that logs everyone out every sixty minutes. It is not going to be fine, and the moment it stops being fine is the moment three hundred people are standing between you and the coffee.

So do not plan for connectivity. Plan for the degraded mode, and treat the good case as a pleasant surprise.

The design point: the scan completes on the device

There is exactly one property that determines whether a bad network is an inconvenience or an incident: whether a scan can be resolved without a round trip.

If it can — if the pass carries a signature the device can verify and the device holds the result until it can hand it back — then the queue keeps moving at the speed of the volunteer, and the network becomes a background sync problem. Scans are held locally and posted when the connection returns.

If it cannot, the queue moves at the speed of the worst network hop in the building, and when that hop stops, so does everything. There is no operational technique that recovers from this. It is decided months earlier, by what you chose to run.

The same reasoning is why check-in should be a web page on the volunteer's own phone rather than an app. Not because apps are bad, but because at 07:50 on the day you will be handing a link to a volunteer who was not at the briefing, and "open this link" succeeds where "install this, sign in, and approve the permissions" does not.

What offline actually costs you

Be honest about the trade, because a page that claims offline check-in without naming the cost has hidden a problem rather than solved one.

While a device is offline it knows what it has scanned. It does not know what the device at the other gate has scanned. So the one thing you genuinely lose is real-time duplicate detection across devices: if the same pass is presented at the north door and then at the south door during the outage, both scans succeed locally and the collision only surfaces when they sync.

This is the right trade — a false admission is recoverable, a stopped queue is not — but it has to be handled rather than ignored. That is what a conflict queue is for: the collisions land in one list, with both timestamps and both devices, and a supervisor works them after the rush. Usually it is one person who was let through at the wrong gate and walked round. Occasionally it is a pass that was forwarded. Either way you find out, with evidence, instead of never.

The week before

Test on the venue's network, not on yours. Go to the room. Stand where the desk will be, not where the router is. Load the check-in page on the actual devices.

Then test with the network off. Put a phone in aeroplane mode and scan ten passes. Watch them queue. Turn the network back on and watch them sync. If you have not seen this work with your own eyes, you do not know that it works.

Check the passes people are actually holding. Print one, screenshot one, and open one in the delegate's own mail app on an old phone with a cracked screen and the brightness turned down. That is the real population.

Assign devices to gates, and label them. North 1, North 2, South 1. The command centre showing live arrivals by gate and device is only useful if the device names correspond to places in the building. "iPhone (3)" tells you nothing at 08:45.

Charge everything, and bring more power than you think. A phone running a camera continuously for two hours is a phone at forty per cent by mid-morning. Battery packs at every desk, one per device.

Set up the roles before the day, not on it. Volunteers get the check-in operator role and nothing else — enough to scan and admit, not enough to browse the membership list, with contact details masked. The one supervisor gets the wider role. Granting these at 08:20 in a corridor is how somebody ends up with more access than anyone intended and it is never revoked.

On the morning

Doors open before doors open. Have every device on the check-in screen and a test scan done fifteen minutes before the first delegate. The first scan of the day is the one that finds the problem.

One supervisor, near the door, not on a desk. Their job is exceptions and nothing else, so the queue never waits for a decision. If they are scanning, they are not supervising.

Watch arrival rate, not total. The total goes up all morning and tells you nothing. Arrivals per minute by gate tells you when to open a second lane, and it usually tells you about ten minutes before the queue makes it obvious.

Do not put a device away until it says it has synced. This is the discipline that matters most and is easiest to skip. A phone that goes into a bag with forty unsynced scans is forty people who are, as far as every report is concerned, absent. Walk the line at the end of the rush, get every device back on the network, and confirm the queue is empty before anyone takes a break.

The paper fallback is not a fallback

If everything fails — devices, network, all of it — you will write names on paper. Accept that, but understand what you have chosen: paper is not a check-in system, it is a data entry job you have deferred to a tired person at six in the evening.

If you do fall back to paper, capture enough to reconcile: full name, the pass or booking number, the gate, and the time. Name alone will not reconcile against a list with two people called Sharma. And type it in the same day, while the handwriting is still interpretable and the person who wrote it is still in the building.

Afterwards

Two things are worth twenty minutes on the following morning.

Empty the conflict queue while people remember. Each entry is a small story, and the stories are how you learn that the south gate was letting people through without scanning because the queue got long.

Then read the audit log next to the arrival curve. Overrides cluster around the moments something went wrong, and the cluster tells you where. That is a better account of the day than any headline number, and it is the one thing that makes the next event easier rather than merely later.