Event Entry Where One Ticket Means One Scan

Every organiser knows the door moment. A queue forms, phones are fumbled, screens are dim, and a volunteer is trying to find a name on a list while the next person waits in the rain. QR code ticket entry exists to replace that scramble with a single action: show a code, scan it, and get a clear answer. But the code only helps if it is unique to one ticket, if the scanner checks it against a live record, and if the team knows exactly what to do when the answer is not a clean green tick. A shared event code that anyone can copy will not do that job, however nicely it is printed.

This guide covers the system, not just the square. It explains how one-code-per-ticket entry works, how to issue codes, how to run the door on the day, how to handle duplicates, re-entry, and the guest whose phone has died, and how to keep entry moving when the venue Wi-Fi fails. It assumes you are using a ticketing or check-in tool for validation, because a free QR generator alone cannot mark a ticket as used. FreeQrly can create the codes and the event pages around them, but the used-or-not decision must live in a ticket record that every gate can see, or at least reconcile.

One ticket, one code, one record

The core rule is simple: every ticket carries its own QR code and its own ticket identifier, and no two tickets share the same code. When an attendee registers or buys a ticket, the ticketing platform assigns that unique code and ties it to their ticket record. The code itself almost never contains personal details. It usually holds a unique reference string, often encrypted or signed, that points to a single ticket record in the platform database. The scanner reads the reference, the platform looks it up, and the answer comes back as one of a small set of results: Valid, Invalid, Duplicate, or Expired.

That distinction matters, because it separates two kinds of QR code that organisers often confuse. An event QR code shares the same content with everyone: the schedule, the venue map, the registration page. An event ticket QR code is unique to each attendee, and its job is validation, duplicate prevention, and attendance tracking. Use the shared code to tell people about the event. Use the unique code to let them in. If you print the same code on every ticket, you have built a poster, not a ticket, and anyone who photographs it can walk in with it.

What the scanner should return, and why four answers beat two

A good door scanner does not just say yes or no. It distinguishes Valid, meaning a first scan of a real ticket; Invalid, meaning the code matches no ticket on file and is likely fake, photoshopped, or for a different event; Duplicate, meaning the ticket has already been scanned; and Expired, meaning the ticket is real but outside its valid date or time window. Staff need those distinctions, because each one calls for a different response. A Valid scan means welcome them in. An Invalid scan means check the ticket carefully and send the guest to the help desk, not into an argument at the gate. A Duplicate scan means stop, verify identity, and escalate. An Expired scan means explain the window and offer the correct session or a rebooking route if one exists.

Train staff on the exact wording and colour of each result in your chosen tool, and rehearse the duplicate case specifically. In the moment, a volunteer who has only practised the happy path will hesitate, wave someone through, or argue. A volunteer who has practised the duplicate script — pause, keep the guest politely to one side, call a supervisor, check name and order reference — will protect both the event and the guest, including the guest who is the victim of a forwarded screenshot rather than the person who forwarded it. The supervisor, not the gate volunteer, should make the final call on contested duplicates, and that rule should be written down before doors open.

Issuing tickets that survive the real world

Issue codes early enough that guests can find them, but keep the ticket design simple enough to scan under pressure. The QR code should be large on the ticket, on a light background, with a clear quiet zone around it, and with the ticket identifier printed in human-readable text nearby. That text is the fallback when a code will not scan: staff can type or search the identifier, the surname, the email address, or the order reference. A ticket that only works when its code scans perfectly is a ticket designed for a demo, not a door.

Support both phone screens and printouts. A meaningful share of any audience will print, and older audiences especially, and any scanner that reads a phone screen reads paper more reliably. Do not require guests to download an app to show a ticket. Guests should only need the code from their email or printout; only the door team needs the scanning app. If your flow forces every guest through an app install, account creation, or login at the gate, you have added a queue before the queue.

Running the door: lanes, devices, and the help desk

Door design is queue design. Separate the main scan lanes from the help desk, so that walk-ins, name changes, guests without a phone, and disputed tickets do not block guests who have a working code ready. Put signs before the check-in desk telling guests to have their QR code ready and to turn up screen brightness. That single sign, repeated in the confirmation email, prevents a surprising amount of delay, because dim screens scan slowly, especially outdoors and in bright sunlight.

Use dedicated scanning devices where you can. Staff phones receive calls, notifications, and run out of battery, and a phone that dies mid-rush takes a lane with it. If you must use staff phones, put them in a mode that silences interruptions, charge them fully, and keep power banks at every lane. Keep the camera lens clean, ask guests to hold the code steady in the centre of the scanner frame, and keep the scanner app as the only task on that device during entry. A rehearsal that includes a flat battery, a cracked screen, and a guest with a dead phone will teach the team more than a rehearsal where everything works.

Duplicates, re-entry, and the screenshot problem

Duplicate handling is where ticket entry earns its keep, and where it most often goes wrong. The rule for a single-entry event is that the code is marked used on first scan and refused afterwards. That single control stops reprints and forwarded tickets at the door, provided all gates share the same live record. If two gates scan independently without syncing, the same code can enter twice, once at each gate, before anyone notices. Multi-gate scanning must therefore sync to one live dashboard, or the event must accept that risk and plan a reconciliation step.

Decide the re-entry policy before you sell tickets, and state it on the ticket. Some events are single-entry by design: a concert, a theatre show, a timed exhibition. Others need re-entry: a multi-day festival, a trade show where attendees leave for lunch, a conference with off-site sessions. Many platforms make re-entry a toggle per event, so a concert can disable it and a festival can enable it. Whatever you choose, the scanner behaviour must match the promise. If re-entry is allowed, the scanner should record an exit and a re-entry, not flag the second scan as a duplicate. If re-entry is not allowed, staff need a clear exception process for genuine cases, such as a medical exit, handled by a supervisor rather than by waving the guest through.

Screenshots deserve a specific policy, because they are both a legitimate backup and a fraud vector. A guest who screenshots their own ticket so it is available without signal is being sensible. A guest who forwards that screenshot to someone else is creating a duplicate. The system cannot tell those two cases apart from the image alone, which is why the first scan wins and the second scan is flagged. Communicate that plainly: the first person to scan the code enters, and sharing the code risks losing the ticket. For high-value tiers, add a name check at the gate, so a code alone is not enough. For general admission, accept that first-scan-wins is the control, and staff the help desk to handle the disputes it will occasionally create.

When a duplicate is flagged, follow a short, calm script. Keep the guest to one side so the lane keeps moving. Ask for the order confirmation, the name on the booking, and identification if your event requires it. Check the scan history: when was the code first scanned, at which gate, and under what name? If the first scan was minutes ago at another gate, the guest may have entered, left, and returned without an exit record. If the first scan was hours ago, or at a gate the guest has not visited, treat it as a possible forwarded code and escalate. Never accuse a guest of fraud at the gate. State what the system shows, explain the next step, and let the supervisor decide. The goal is to protect the event without humiliating a guest who may be the victim.

When the network fails: offline scanning and paper backup

Venue Wi-Fi degrades exactly when thousands of phones arrive, and any check-in system that requires a live connection for every scan will stall at the worst moment. Before you commit to a tool, check whether its scanning app holds the full guest list locally and can check in a guest with the network off. Some tools offer offline mode in the app only, while their web dashboard needs a connection, and offline mode usually has to be started while still connected. Test that flow in rehearsal, not on the day.

Offline mode has a trade-off you must plan for: two lanes offline cannot both know a ticket was already used. One guide describes exactly this case, where two devices scanning the same code offline both accept it, and an error only shows when offline mode ends and scans are reconciled. Mitigations include assigning ticket ranges to lanes, so the same code is unlikely to appear at two offline lanes, accepting that duplicates will be flagged on sync and handled by a supervisor, and uploading scans from each device before it goes back online, since scans not uploaded before reconnection can be lost in some tools. The honest summary is that offline mode keeps entry moving, but it weakens duplicate protection until sync. For a high-fraud-risk event, that trade-off may argue for a backup mobile router, a wired connection at the help desk, or a smaller offline footprint, rather than full offline operation.

Keep a paper backup even if you expect a digital flow. A printed alphabetical list, a printed VIP or special-access list, and blank badges or wristbands for manual issue give the help desk a way to admit guests when devices fail, batteries die, or the network drops. Keep the list current: a guest list exported an hour before doors and already out of date is a known failure mode. If the ticketing system and the door app come from the same platform, that export problem largely disappears, because the door list updates as sales update. If they do not, assign one person to refresh the backup list at a fixed time before doors, and note that time on the list itself, so staff know how fresh it is.

Also plan for the guest whose phone has died, whose code will not load, or whose ticket email cannot be found. The help desk should be able to search by surname, email, or order reference, not just by scan, and should be able to re-send a ticket or issue a replacement. That search path is also the accessibility path and the dispute path, so staff it with experienced people, not with whoever is spare. A help desk that can solve a problem in a minute will save a scan lane from a five-minute blockage.

After the doors: attendance, reconciliation, and learning

When entry closes, reconcile. Compare the scanned count against the sold count, list the duplicates flagged, the invalid scans attempted, and the manual admissions from the help desk. That reconciliation is both a fraud check and a planning tool: it shows which gates were busiest, when the peak arrived, and where the help desk was most needed. Share a short summary with the team while the memory is fresh, and note any scanner wording, lane layout, or signage that confused staff or guests. The next event will inherit those notes, or it will inherit the same queue.

For the surrounding pieces, see QR codes for events for registration and schedule codes, how to scan a QR code for the guest side, and QR code troubleshooting when a code will not scan at all. FreeQrly supports all 17 QR code types, and event pages, schedule links, and feedback codes can all sit alongside ticket entry in one event workflow, but the ticket validation itself must live in a ticketing record where one code maps to one ticket, and where a second scan is a decision, not a surprise.