On-site check-in at scale: the ops playbook

What actually breaks at the door

After running check-in for hundreds of large-format events, the failures cluster into a small number of categories. None of them are exotic. All of them are predictable. Most of them are testable in advance.

• Venue Wi-Fi capacity — the contracted bandwidth was sized for the AV team, not 5,000 attendees opening Slack.
• Badge printer queue depth — printers that handle 200 badges/hr fall apart at 1,200/hr peak.
• QR scan failure rate — phone screens at 40% brightness in a sunlit lobby simply don’t read.
• Last-minute registrations — 7-12% of attendees register the morning of, and your data sync needs to be near-real-time to handle them.
• Manual override volume — duplicate accounts, name corrections, comp tickets. You will need a fast manual-add path.

{% include post-callout.html variant=”gradient” title=”The 5-minute drill” body=”Walk to the venue at 6 AM the day of. Stand where the line will be. Open your phone. Try to load the event page. Try to open the check-in app. If either takes more than three seconds, you have a problem the network team needs to know about by 7.” %}

The dual-path principle

At scale, no single check-in path can be your only path. The pattern that works:

1. Self-service kiosks for attendees with a clean QR code — handles 60-70% of the line.
2. Staffed scanner stations for attendees with phone, paper, or printed-badge issues — handles 20-25%.
3. Service desk for any case requiring lookup, correction, or comp ticket — handles 5-10%.

The numbers shift per event. The ratio is stable. The mistake is funneling everyone through the staffed line because it’s simpler — what’s simple at 200 attendees is a fire at 5,000.

At 5,000 attendees, your operational margin for error is roughly two minutes per failure mode. Plan accordingly.

What to instrument

If your check-in app can’t show you these four numbers in real time, you’re flying blind:

• Throughput per minute, per station
• Average scan-to-print latency
• Cumulative arrivals vs. expected curve
• Manual-override count and reasons

The goal isn’t to optimize during the event. The goal is to know which failure mode is hitting you, so the recovery action is targeted instead of panicked.

Recovery, not prevention

The events that go well aren’t the ones where nothing breaks. Something always breaks. The events that go well are the ones where the recovery loop is shorter than the line’s patience. That’s what you’re designing for.