The wrong check-in technology doesn't fail in a demo — it fails in the first 30 minutes of your event, in front of 1,000 queuing attendees. Choosing the right onsite registration for large-scale exhibitions starts with one metric vendors rarely put in their pitch decks: sustained throughput under peak load. This article shows you what to benchmark, what to test, and what to walk away from before you sign a contract.
Why Vendor Demos Lie About Throughput
Vendor demos run under ideal conditions — private Wi-Fi, pre-loaded data, expert operators. The number that matters is not demo throughput. It is sustained throughput with degraded Wi-Fi, offline fallback active, and staff with 90 minutes of training.
- 1Network conditionsVendor demos use a private hotspot. Your convention centre runs shared Wi-Fi under load from hundreds of simultaneous devices. These are not the same network condition.
- 2Offline fallback activeAny production check-in deployment must run with offline mode enabled. If the system only performs at claimed speed when online, that claimed speed is not real.
- 3Operator experienceDemo throughput is typically achieved by the vendor's own technicians. Your Day 1 staff have had 90 minutes of training. Measure both and expect a gap.
- 4Database sizeA demo database of 500 records performs differently to a live attendee database of 18,000 records, particularly on systems that query a remote server per scan rather than caching locally.
It was 9:20 AM at a 6,000-pax trade show in Kuala Lumpur. Twenty minutes after doors opened, the queue was already 80 metres into the pre-function area and there was no realistic path to recovery before the first keynote. The system had quoted 120 attendees per hour. On venue Wi-Fi with offline mode active, it was doing 38. The vendor had never tested it that way.
When you frame the throughput question correctly — degraded network, offline fallback active, trained-but-not-expert staff — a system that claims 120 attendees per hour in a demo might genuinely process 38 to 45 per hour in a live convention centre environment. Organisers evaluate check-in systems on feature lists and price. They do not ask for a throughput stress test against their actual peak load scenario.
The 3 Numbers That Actually Predict Day 1 Performance
Before evaluating any system, calculate your peak arrival rate, your processing time target, and your required lane count. Every vendor conversation starts with these three numbers — not the feature sheet.
- 1Peak Arrival Rate (PAR)Take 65–70% of total Day 1 expected attendance. Divide by 90 minutes. This gives you arrivals per minute at peak. This is the load your system must sustain — not average load across the full day.
- 2Processing time targetTarget 8–12 seconds per attendee per lane. Above 15 seconds creates visible queue build-up within 20 minutes at PAR. Ask your vendor to demonstrate this time under offline fallback conditions.
- 3Lane count requiredDivide your peak arrivals per minute by the number of attendees one lane handles per minute at your target processing time. Add 25% buffer for walk-ins, reprints, and intervention events. Round up.
Event: 5,000-pax exhibition in Bangkok. 65% arrive Day 1 morning — that is 3,250 arrivals across a 90-minute window, approximately 36 arrivals per minute. At a 10-second processing target, each lane handles 6 people per minute. Minimum lanes needed: 6. With 25% buffer: 8 lanes. Any vendor proposing 4 kiosks for this event is undersizing the deployment by half.
How to Stress-Test a System Before You Commit
A proper pre-event evaluation includes a live throughput test — not just a feature demo. Require the vendor to run five specific tests: offline mode, degraded network, full database load, badge reprint timing, and staff cold-start. Any system that cannot pass all five is not production-ready for large-scale events.
- 1Offline mode demonstrationDisconnect the system mid-demo. Check-in must continue without interruption. Data must sync automatically when connection restores. If it requires a reboot, it will fail on site.
- 2Degraded network simulationRun the system on a mobile hotspot throttled to 3 Mbps — the approximate performance of shared convention centre Wi-Fi under load. Record the per-attendee processing time. This is your real number.
- 3Full database load testLoad your full expected attendee database — minimum 10,000 records for large events — before the demo. Processing speed degrades significantly on systems that query a remote server per scan rather than caching locally.
- 4Badge reprint timingTime how long a reprint takes when attendee details need correcting. At large events, 3–8% of attendees require intervention at check-in. This time adds directly to queue length if reprints are not isolated to a separate lane.
- 5Staff cold-start testHave a non-technical staff member operate the system after a single 30-minute training session. If they cannot process a clean check-in without supervisor help, the system is too complex for your Day 1 staffing reality.
Event: 10,000-pax trade show, Singapore. Pre-event stress test revealed the proposed kiosk system reduced to 22 attendees per hour when offline mode was active and the badge print job queue exceeded 15 items. Caught in the test lab — not on Day 1. The vendor patched local queue management before deployment. Final Day 1 throughput: 94 per hour per lane.
For a deeper look at how the five core check-in technologies compare, the complete guide to onsite registration for large-scale exhibitions in Asia covers the full technology landscape.
The Walk-In Problem Organisers Underestimate
Walk-in attendees at APAC trade shows represent 15–30% of total attendance and arrive in the same peak window as pre-registered attendees. Routing walk-ins through the same lane as pre-registered attendees spikes your average processing time from 10 seconds to 25–40 seconds per person. Separate the lanes — or plan for queue failure.
- 1Data capture at arrivalWalk-ins require name, company, and contact detail collection at the point of check-in — not at a separate registration desk downstream. Every step out of the main flow adds 45–90 seconds per person.
- 2Integrated payment processingIf your event charges a walk-in fee, payment must be integrated into the check-in flow — not handled at a separate cashier. Separate payment queues merge back and create compounding delays.
- 3Template-based badge printingWalk-ins cannot retrieve a pre-printed badge. They need a clean print from a template. This takes 8–15 seconds per badge. If this job queues behind pre-registered reprints, it stalls the entire lane.
- 4Dedicated lane designationDesignate separate lanes for walk-ins and sign them clearly at the entrance. When both flows share a lane, your effective lane throughput halves within the first 15 minutes of the peak window.
Event: 8,000-pax industry trade show, HKCEC. Walk-in rate: 22% (1,760 people). Before lane separation: average processing time across all lanes — 31 seconds per person. After dedicated walk-in lanes: pre-registered average reduced to 9 seconds, walk-in average 58 seconds. Overall queue cleared 40 minutes faster on Day 2 than Day 1.
The walk-in workflow is covered in detail in walk-in registration at trade shows.
What Separates Systems That Hold Under Pressure
The check-in systems that survive peak load share four architectural characteristics: local database caching, queue-managed badge printing, automatic offline sync, and hardware failover. Evaluate these explicitly — not as bonus features but as minimum requirements.
| Architectural Feature | What It Does | Risk If Absent | Priority |
|---|---|---|---|
| Local database caching | Full attendee records stored on-device — not fetched per scan from cloud | Throughput collapses under shared network load | Critical |
| Queue-managed badge printing | Print jobs managed locally with automatic prioritisation | 15-item print queue adds 20+ seconds wait per job | Critical |
| Automatic offline sync | Check-ins in offline mode sync silently when connectivity restores | Check-ins lost on connection failure; manual audit required | Critical |
| Hardware failover path | Single kiosk failure routes to adjacent lanes automatically | One device failure requires IT call; effective lane count drops mid-peak | High |
The performance gap in real numbers: A cloud-query-per-scan system processes 110 attendees per hour in a demo on a 50 Mbps connection. On venue Wi-Fi at peak check-in load, the same system processes 31 per hour — because every scan triggers a round-trip to a server simultaneously serving 200 other check-in transactions. That gap is the throughput failure that creates 80-metre queues.
This is precisely where organisers who evaluate on price discover the gap. That is why experienced event operations teams specify onsite registration systems by their offline-mode throughput benchmark first — and their feature list second.
A post-event audit of onsite check-in failures across 180 large-scale MICE events in Southeast Asia found that 71% of Day 1 queue incidents were caused not by hardware failure but by disconnected systems — registration data in one platform, badge production in another, access control in a third. Replacing the printer model does not fix the architecture.
Info Salons Asia's integrated event technology solutions are built specifically to eliminate that architecture problem — a single connected platform where registration, badging, access control, and real-time reporting run from one source of truth, stress-tested against your actual peak load scenario before deployment.
Frequently Asked Questions
Common questions about onsite check-in technology for trade shows and exhibitions
For pre-registered attendees at a trade show, target a minimum of 90 attendees per hour per lane under offline fallback conditions. Above 120 per hour per lane is achievable with local database caching and queue-managed badge printing. Below 60 per hour per lane in a live environment indicates a systemic architecture problem — not a staffing problem.
Calculate your peak arrival rate: take 65–70% of total Day 1 expected attendance, divide by 90 minutes, convert to arrivals per minute. Divide that by the number of attendees one lane processes per minute at a 10-second processing target. Add 25% buffer for walk-ins, reprints, and interventions. Round up — never round down.
Both work at scale when correctly specified. Self-service kiosks reduce staffing costs and handle pre-registered attendees efficiently. Staffed counters are essential for walk-ins, VIPs, and any attendee requiring intervention. Most large-scale APAC events use a ratio of 3:1 self-service to staffed lanes as a baseline, adjusted for expected walk-in rate.
Any check-in system deployed at a large-scale event must have local offline caching enabled as the default operating state — not as a fallback. Check-ins recorded offline should sync automatically when connectivity restores, with no data loss and no duplicate entry. Require your vendor to demonstrate this in the pre-event stress test with the connection cut mid-session.
For events above 1,000 attendees: minimum 8 weeks lead time for configuration, database load testing, and staff training. For events above 5,000 attendees: 12 weeks minimum, with a full on-site rehearsal at the venue at least one week before event day.