GUIDE · THE DAY BEFORE
What to check before doors, whatever you run it on.
This is our own event-day runbook with the Bloop-specific steps taken out. It is useful with a spreadsheet and a clipboard, which is rather the point: most show-day failures are process failures wearing a software costume.
The day before doors
- Every gate and door has a named person, a device, and a charger. Count them physically.
- Print the current sheets last, not first. A sheet printed on Thursday is a Thursday sheet.
- Walk one person through the full journey: application, approval, pass, scan. End to end, on a real device.
- Check the access matrix against the physical site. A zone that exists in software and not on the ground causes arguments at 06:00.
- Confirm who can approve a late change, and how the gates hear about it.
Connectivity, honestly assessed
- Test signal at every entry point, not at the site office. Docks, basements and back gates are where it fails.
- Know what your system does when the signal drops, before it drops. Queue? Refuse? Cache?
- Have a paper fallback for the two or three gates most likely to lose signal, and know who holds it.
- Agree the radio phrase for "the system is down at gate 4" so it is not a two-minute conversation.
The people layer
- Gate staff briefed on deny reasons, not just on scanning. "Wrong zone" and "already scanned" need different responses.
- Someone senior owns exceptions, and gate staff know their name and how to reach them.
- Contractors arriving before the pass office opens: decide the answer now, not at the barrier.
- Medical, welfare and security know how to look someone up if a pass is lost.
On the day
- Check the first ten scans at each gate personally. Configuration errors surface in the first ten or not until the queue.
- Watch deny reasons by gate through the first hour. A spike at one gate is usually a configuration problem, not a fraud problem.
- Keep a running note of every manual override. It is the record you will want at the debrief.
After
- Export the entry data and the change log while the event is fresh.
- Record what actually happened against what was planned, including the workarounds.
- Note which pass types were wrong. That is next year's setup, already half done.