Free Event Check-In Lane Calculator
Published advice puts a check-in lane anywhere between 60 and 500 people an hour, and that single number decides your whole staffing plan. So this calculator makes it an input instead of guessing it for you — and shows you how much the answer moves when it changes.
Nothing you type leaves your device. This is a few lines of arithmetic running in your own browser — no account, no network request, nothing stored. Your headcount and door plan stay yours, which matters when the guest list is confidential before the event.
Start from a typical event
Everyone who will come through the door, not just ticket sales.
Most events see the majority turn up shortly before the opening session.
The crush, not the whole doors-open period.
The input that decides everything. Time it yourself — door to door, including the attendee finding their code.
Scanning positions working at the same time, not total staff on shift.
How Much Does the Scan Speed Actually Matter?
This is the table worth looking at before you book staff. It holds your headcount and arrival window fixed and varies only the seconds per attendee — the one number published guidance cannot agree on. If the lane count changes across these rows, then your staffing plan is not really a plan until you have measured your own rate.
| Seconds per attendee | Per lane, per hour | Lanes needed | Typical of |
|---|
How the Calculation Works
The arithmetic is deliberately simple, because the uncertainty is in the inputs, not in the model. Dressing it up in queueing theory would hide that.
Step 1 — find the peak, not the total
A door is overwhelmed by the rate people arrive at, never by the headcount. So the first step throws the headcount away and keeps the busiest window: peak arrivals = people × share arriving in the window. A 1,000-person conference spread over three hours is an easier door than a 300-person dinner where everybody shows up in the last ten minutes.
Step 2 — convert that to a rate
Divide the peak arrivals by the length of the window to get an arrival rate in people per minute. This is the number your lanes have to match.
Step 3 — work out what one lane does
A lane that takes s seconds per attendee serves 60 ÷ s people per minute. At 8 seconds that is 7.5 a minute, or 450 an hour. Multiply by the number of lanes for your total service rate. Note what counts as a second here: not the instant the camera reads the code, but the whole interaction — the attendee reaching the front, finding their code, the scan, the result appearing, and them moving off.
Step 4 — compare the two rates
If the service rate is at or above the arrival rate, no lasting queue forms and people wait roughly one service time. If it is below, the queue grows at the difference between the two for as long as the window lasts. The backlog when the window ends is (arrival rate − service rate) × window, and the last person to join that queue waits backlog ÷ service rate minutes. The minimum lane count is the smallest whole number of lanes that makes the comparison come out even: ⌈peak arrivals × seconds ÷ (window × 60)⌉.
Step 5 — treat the answer as a floor
Everything above assumes arrivals land at a steady rate. They do not. Real arrival curves spike, and a spike inside your window produces a longer queue than this model shows even when the totals match exactly. So the result is a best case. The buffered figure adds about a quarter more capacity, which is where published planning advice converges for breaks, device failures and bursts, and it counts an exception desk separately — because the moment a lane has to deal with a missing booking it is not a lane any more.
Why Nobody Can Tell You Your Scan Rate
These are per-lane throughput figures published as planning numbers by event-industry sources. They are estimates offered by companies selling event software, not measurements, and they disagree by nearly a factor of ten. The useful conclusion is not an average of them — it is that the figure depends almost entirely on what your staff are doing besides scanning.
| Setup | People per hour per lane | Implied seconds each |
|---|---|---|
| Staffed desk, scan and print a badge | 60–120 | 30–60 s |
| Staffed lane, phone scanning pre-issued codes | 150–200 | 18–24 s |
| Staffed lane with a bag or ID check | ~200 | ~18 s |
| Self-serve kiosk, pre-registered guests | 250+ | ~14 s |
| Dedicated 2D scanner, code already in hand | 300–500 | 7–12 s |
The reliable way to get your own figure takes about five minutes: line up twenty colleagues with their codes on their phones, run them through exactly the process you will use on the day, and divide the total elapsed time by twenty. That number beats every row in this table, because it includes your venue's lighting, your staff, your network and your badge design.
A Worked Example
A 500-person conference. Experience says about 70% arrive in the half hour before the keynote, and a dry run measured 8 seconds per attendee. You have budgeted two lanes.
- Peak arrivals: 500 × 70% = 350 people in 30 minutes.
- Arrival rate: 350 ÷ 30 = 11.7 people per minute.
- One lane at 8 seconds: 60 ÷ 8 = 7.5 a minute, or 450 an hour.
- Two lanes: 2 × 7.5 = 15 a minute, which is above 11.7 — the door keeps up.
- Minimum lanes: ⌈350 × 8 ÷ 1,800⌉ = ⌈1.56⌉ = 2. With the buffer, 3, plus one exception desk.
Now cut it to one lane and the same event falls apart: capacity is 7.5 a minute against 11.7 arriving, so by the end of the half hour 125 people are still queueing, the last of them waits nearly 17 minutes, and the door does not clear until 47 minutes after it opened — seventeen minutes into a keynote that 350 people were meant to be sitting down for. The difference between a smooth door and that is one member of staff.
What the Arithmetic Cannot See
Lane counts are the easy part of a door. These are the things that turn a sound plan into a queue on the night, and none of them shows up in the numbers above:
- Codes on phone screens. A cracked screen, deep-dimmed brightness or a screen protector in low light is the single most common reason a scan takes three attempts instead of one. Our guide to why a barcode will not scan from a phone screen covers what to tell attendees in advance.
- Duplicate detection needs the network. An offline device only knows the attendee list it last downloaded, so two offline doors can both admit the same code before either syncs. If that matters, keep devices online or split code ranges by gate.
- Screenshots and forwarded tickets. A QR code is just data, so a screenshot reproduces it perfectly and nothing in the image can prevent that — only a first-scan-wins check at the door can. See whether a screenshot of a ticket QR code works.
- Badge print size. A code too small or too tightly cropped costs seconds on every single scan, and those seconds are exactly the input above. The print size calculator gives the width and quiet zone your badge actually needs.
- What the code contains. Any scanner pointed at a badge can read it, so a code holding a name and email is publishing them. GDPR Article 5(1)(c) limits personal data to what is necessary for the purpose, and for entry validation that is an opaque ticket ID — nothing more.
- One queue, or several? A single feeder queue serving all lanes beats one queue per lane, because a lane never sits idle while another has people waiting. The model above assumes the single-queue arrangement.
Related Tools and Guides
Frequently Asked Questions
How many people can one QR check-in lane actually process?
There is no settled figure, and anyone quoting one precisely is guessing. Published event-industry estimates for a single staffed QR lane range from about 60 people an hour at the pessimistic end to 300–500 an hour for a dedicated 2D scanner with pre-registered guests. The spread is real, not sloppiness: it depends on whether staff also print badges, check ID or search bags, how fast the attendee finds their code, and whether validation waits on a network round trip. That is why this page asks you for seconds per attendee rather than assuming it — at 3 seconds a lane does 1,200 an hour, at 20 seconds it does 180, and a plan built on the wrong end of that range is out by a factor of six.
Why does the calculator ask for an arrival window instead of just the headcount?
Because the headcount is not what overwhelms a door — the arrival rate is. A 1,000-person conference where everyone drifts in over three hours needs far fewer lanes than a 300-person awards dinner where almost everybody turns up in the ten minutes before the room opens. Event planning guidance consistently says to size the door to the busiest window rather than total attendance, which is why the two inputs here are the share arriving in that window and how long it lasts.
What queueing model does this use?
A deterministic fluid model. Arrivals are assumed to land at a steady rate across the busiest window, and each lane serves at a steady rate of 60 divided by your seconds-per-scan. If total service capacity is at or above the arrival rate, no lasting queue forms; if it is below, the backlog grows at the difference for as long as the window lasts, and the longest wait is that backlog divided by your total service rate. It is the same arithmetic the published lane formulas use, shown step by step.
Is the result a best case or a worst case?
A best case, and deliberately so. Steady arrivals are the friendliest assumption you can make — real arrival curves spike, and a spike inside your window produces a longer queue than this model shows even when the totals match. Treat the lane count as a floor rather than a recommendation. That is why the page also gives a figure with a buffer added: industry planning advice converges on roughly 20–25% spare capacity for breaks, device failures and bursts, plus a separate desk for problem cases.
Why a separate exception desk rather than one more lane?
Because a scanning lane is only fast while every code works. The moment someone arrives with no booking, a refunded ticket, a name that does not match or a dead phone battery, that lane stops being a lane and becomes a help desk, and everyone behind them waits. Keeping one staffed position off the scanning rota to absorb those cases protects the throughput of all the others, which is why the recommended figure here counts it separately instead of adding it to the lane count.
Does a check-in app need to be online to catch a duplicate ticket?
To catch every duplicate, yes. An offline device can only compare a scan against the attendee list it last downloaded, so it cannot know about a ticket refunded since then, and two offline devices on different doors can both admit the same code before either syncs. Vendor documentation is explicit that offline check-ins queue until reconnection, and some tools simply accept a repeat scan without flagging it at all. If duplicate detection matters at your door, either keep the devices online or run a single device per code range so no code can be presented at two gates.
What should a check-in QR code contain?
An opaque identifier, not personal data. Anything encoded in a QR code is readable by any scanner that happens to be pointed at the badge, so a code carrying a name, email and phone number is handing those out to strangers. GDPR Article 5(1)(c) requires personal data to be limited to what is necessary for the purpose, and for validating entry the necessary minimum is a reference that means nothing without your list. Encode a random ticket ID and keep the person behind it in your own records.
Is anything I enter here sent to a server?
No. The whole calculation is a few lines of arithmetic running in your own browser, with no network request and nothing stored. Your headcount and your door plan are commercially sensitive before an event, and there is no reason a size calculator should ever see them.
Measure Your Own Seconds Per Scan
The one input that drives this calculation is the one you can only get by timing it. Scan & Generate timestamps every scan and exports the history, so a dry run over 20 badges gives you your real seconds-per-scan — then come back and plan the door on your own number instead of a vendor average.