All guidesCheck-in

QR check-in vs manual attendee lists

Manual lists do not fail gracefully. They fail at the worst moment, which is the ten minutes when everyone arrives at once.

9 min readUpdated By AnnexHub

Illustration contrasting a long unrolled paper attendee list with a phone showing a QR code

Every organiser who has run a door with a printed list already knows the failure mode. It is not that the list is wrong. It is that at 8:55am, when 300 people arrive in the same eight minutes, one person with a highlighter becomes the bottleneck for the entire event, and there is nothing anyone can do about it from the inside.

This is a comparison of the two options as they actually behave on event day, rather than as they look in a planning meeting.

The honest case for manual lists

Manual lists are not stupid. They have real advantages and it is worth being clear about them before dismissing them:

  • Zero setup. Export a spreadsheet, print it, done.
  • Zero dependencies. No wifi, no devices, no batteries, no vendor.
  • Anyone can operate one. No training, no app, no login.
  • They fail visibly. If the list is wrong, you can see it and fix it with a pen.

For an event of 40 people in a meeting room, a printed list is the correct tool and anything else is overhead. The question is where the crossover point sits.

Where manual lists break

Throughput

Finding a name on a printed list is a linear search performed by a human under social pressure. It takes as long as it takes, and it gets slower as the list gets longer and the queue gets more visible.

A QR scan is a constant-time lookup. It does not care whether the list has 80 names or 800.

The practical effect is not that QR is faster per guest. It is that manual check-in degrades as the event grows while QR does not.

Arrival is not spread out

The planning assumption is that guests arrive across a 60-minute registration window. They do not. Corporate guests arrive in a spike, because they leave the office together, they share transport, and they all target the same start time.

Design for the spike, not the average. On our events, roughly 60% of the room arrives inside a single 15-minute window immediately before the programme starts. For a 500-person event that is 300 people through the door in 900 seconds. The maths is unforgiving regardless of which method you pick, but only one of the two methods lets you add capacity by adding a second person with a phone.

Duplicate and double entry

Two check-in tables working from two printed copies of the same list will double-count people, and you will not find out until you reconcile afterwards. Two scanners working from the same live event will not, because they are writing to the same record.

The one that taught us this

  1. A developer conference on a university campus in Kuala Lumpur, north of 350 attendees. Annex CS ran the logistics.

Registration at the door was slower than the arrival rate. That is the whole failure, and it sounds small written down. It was not small. The queue outside meant we could not start on time, and the start time was the only fixed point the rest of the day hung off. Every speaker slot behind it compressed or slipped. The people running the programme spent the morning recalculating a timetable instead of running an event, and the day finished late.

Here is the part that matters for your budget rather than your blood pressure. We got away with it because the university sponsored the venue. Running over cost us nothing.

Put the identical morning in a commercial hall and one of two things happens. Either you pay overtime on the room and blow a budget that was signed off months earlier, or you do not, and the air conditioning goes off at the contracted hour while 350 people are still in their seats in Kuala Lumpur. Neither of those is a check-in problem on the invoice. Both of them are a check-in problem in fact.

That is the honest reason to care about the door. A slow queue does not only look bad in the lobby for twenty minutes. It spends money at the far end of the day, in a line item nobody traces back to the morning.

The headcount you report

Manual lists produce an approximate number. Ticks get missed during the rush, walk-ins get written in a margin, and someone transcribes the whole thing into a spreadsheet afterwards from memory and handwriting.

For an internal event nobody cares. For a client event, that number is the deliverable. It goes into the post-event report, it justifies the budget, and sometimes it determines what you invoice. A number derived from a scan log is defensible. A number derived from highlighter marks is not.

Where QR check-in breaks, and how to not let it

QR is not free of failure modes. It has three, and all three have a standard answer.

The venue wifi dies. This is the most common one and the most damaging, because it happens at peak arrival. The answer is an offline-capable scanner: scans are stored on the device and synced when the connection comes back. AnnexHub's check-in app does this as a progressive web app with an offline scan queue, so the door keeps moving with no connection at all. If a platform cannot do this, it is not suitable for a hotel ballroom.

The guest cannot find their QR code. They deleted the email, they changed phones, their corporate mail filter ate it. The answer is a name search fallback in the same app, so the door staff can check someone in by name in five seconds without leaving the flow. Any scanner without a search fallback will produce a manual list anyway, just an unofficial one.

Phone batteries and screen brightness. Guests arrive at 4% battery with the screen dimmed. Physical badges or a printed QR at the door solve this. So does the name-search fallback.

Notice that all three answers are things you check for during evaluation, not things you solve on the day.

Side by side

Printed or spreadsheet listQR check-in
Setup effortNoneRegistration page and ticket send
Speed per guestDegrades as the list growsConstant regardless of list size
Add a second laneSecond copy, risk of double-countSecond device, same live record
Duplicate detectionManual, discovered afterwardsImmediate, at the door
Walk-insWritten in the marginRegistered and checked in on the spot
Works with no internetAlwaysOnly with an offline-capable scanner
Headcount accuracyApproximateExact, with timestamps
Live arrival visibilityNone until you countRunning count during the event
Post-event dataRetyped from paperAlready structured
Failure modeSlow, visible, humanFast, invisible until sync

The thing QR gives you that manual cannot

Live arrival data during the event. Knowing at 9:10am that 240 of 500 have arrived changes decisions: whether to hold the start, whether to open a second lane, whether to tell the kitchen to delay. With a manual list, that number does not exist until someone stops working to count.

A reasonable rule of thumb

  • Under 50 guests, single entrance, no client deliverable: a printed list is fine.
  • 50 to 150: either works. QR pays off mainly in the post-event data.
  • Over 150, or any event where the headcount is reported to a client: QR, with an offline-capable scanner and a name-search fallback.
  • Over 500, or multiple entrances: QR is the only method that scales by adding people, and you should plan lanes explicitly.

The hybrid that actually works

The best-run doors are not purely one or the other. They are QR-first with two deliberate fallbacks:

  1. Scan the QR from the guest's phone. This covers the large majority.
  2. Search by name in the same app for anyone who cannot produce a code.
  3. Walk-in registration in the same app for anyone who was never on the list.

All three write to the same attendee record, so the headcount stays correct and nothing lands in a notebook. That is the actual upgrade over a manual list: not the scanning, but the fact that every path through the door ends in the same place.

Try it on a real event

The free tier covers one live event up to 50 guests.

Registration page, QR tickets and door check-in, including the offline scan queue. Enough to test the door properly before you commit to anything.