QR-code check-in software should help staff decide whether a ticket is valid for admission, recognize a ticket already used and handle exceptions at the entrance. Its behavior across several phones and during a network outage matters more than the QR graphic itself.
Connected phones can share the ticket's current check-in state. A disconnected device may instead work from a downloaded list and keep its own admissions until it reconnects. Those are different operating conditions: a locally accepted scan does not tell another offline entrance that the same ticket has just been used.
What a check-in system must answer
At the door, a staff member should be able to answer three questions quickly: is this person allowed in, what action is safe if there is an exception, and what will be recorded? Every other feature is secondary to that.
| Situation | The desired outcome | The risk if it is unclear |
|---|---|---|
| Valid ticket | Fast confirmation with enough identifying context | Slow queues and manual searching |
| Duplicate scan | A visible warning and a defined escalation path | Either admitting the same ticket twice or wrongly refusing a guest |
| Refunded or canceled order | Clear status and staff guidance | Door staff improvise financial decisions |
| Wrong event or date | A clear explanation and next action | Guests are sent to the wrong entrance or support channel |
| Transfer or guest list | Identity and entitlement can be checked appropriately | A valid purchaser is confused with a participant |
| Walk-in | A controlled sale or registration path | Cash, capacity, and attendee records diverge |
The exact user interface can differ. The operating result should not.
Rehearse at the entrance
Before you rely on a system, assign two staff members and use the actual phones, tablets, scanners, network, entrances, and roles planned for the event. Create test tickets and run the cases below.
- Scan a valid ticket at each entrance.
- Scan the same ticket twice and observe the second device’s response.
- Scan an order that has been refunded or canceled.
- Test a customer whose booking or attendee name was changed.
- Test a complimentary ticket and a staff or guest-list entry.
- Turn connectivity off only if the vendor says offline operation is supported; then reconnect and inspect the resulting state.
- Ask a door staff member to resolve an exception without granting them payment-refund permission.
- Compare checked-in count, remaining capacity, and finance or order records after the test.
Record what happened. “It scanned” is not a pass condition if the duplicate warning, refund status, reconciliation, or staff permissions were wrong.
Offline check-in uses local records until devices reconnect
Some venues have unreliable connectivity; some have no usable network at all. “Offline scanning” can mean different things: a device may retain a downloaded guest list, accept validations locally, queue updates, or synchronize later. It may not be able to know that another disconnected entrance just scanned the same ticket.
A downloaded list reflects the information available at its last update. A ticket sold, refunded or transferred afterward may not be represented correctly on that disconnected device. Local check-ins also cannot update another offline phone in real time.
For example, two disconnected entrances could each accept the same ticket from their own copy of the list. Reconnecting can bring those records together, but it cannot undo the two admissions. A venue therefore needs a defined way to handle duplicates and update capacity after an outage, rather than treating later synchronization as protection at the door.
For software offering offline scanning, the entrance rehearsal should establish what the device downloads, how current it is and how conflicts appear after reconnection. The Gomry procedure below covers check-in and the admission fallback without assuming that another product's offline workflow applies.
Design staff roles before opening the doors
The person scanning tickets should rarely have unrestricted access to refunds, customer data, pricing, or event configuration. Define roles such as entry staff, supervisor, box office, and administrator. Then decide which exceptions each role can resolve.
| Role | Typical safe action | Escalate when… |
|---|---|---|
| Entry staff | Validate ticket and mark attendance | A status conflicts with the customer’s claim |
| Supervisor | Approve a documented access exception | The decision changes money, policy, or capacity materially |
| Box office | Sell permitted walk-ins and follow defined transfer/refund policy | Payment dispute or non-standard exception |
| Administrator | Change event configuration and permissions | The change affects all staff or future buyers |
Give each role a clear escalation route so a failed scan does not require the entire team to stop.
The customer record matters more than the QR graphic
One buyer may buy several tickets for other attendees. A person’s email address, the order owner, the attendee identity, consent, accessibility information, and admission status are not automatically the same record. Ask what the scanner shows, what it stores locally, and whether staff can see only the minimum needed to admit the guest.
Collect less at the door, not more. Confirm your privacy notices, retention practices, device security, and local requirements with appropriate advice. Ticketing software does not remove those responsibilities.
Accessibility and human fallback
QR is a means, not the admission policy. Plan a fallback for a customer with a dead phone, a printed confirmation, a screen-reader issue, a name mismatch, or a ticket bought by a friend. Staff should know how to find an order without turning the line into a public support desk.
Test the signage too: where customers queue, which entrance applies, what they need ready, and where exceptions are handled. A fast scanner cannot fix confusing arrival information.
Data and integrations
If check-in must update another system, define the required event in plain language: for example, “when this attendee is admitted, update their profile” or “when capacity reaches a threshold, notify the operations team.” Then validate the current endpoint, event, payload, permissions, delivery/retry behavior, and failure path.
Gomry's API can retrieve attendee records, while its published webhook list covers supported payment, subscription and form-response changes. It does not currently include a scan notification. An attendance integration therefore needs an API-based retrieval workflow rather than relying on a webhook that fires at check-in. The API and webhook guide explains the available records and notification limits.
Using the Gomry scanner
Staff open Manage event, then Attendees, then Scan to validate tickets in the mobile browser. A ticket already validated produces an already checked in indication. Give each entrance a reliable connection and an agreed fallback procedure so staff can resolve a warning without admitting the same guest twice.
The Check-in Only role can consult participants and manage check-in and check-out, without access to revenue, payments, settings or the team. Express Mode ON checks in the tickets associated with the QR immediately. Turn it OFF to review and select individual tickets. Staff can also find a guest by name in the dashboard and check them in manually.
Frequently asked questions
Can a screenshot of a QR code be reused?
A well-designed ticketing workflow should record first use and warn on later scans. Staff still need a customer-service policy for legitimate disputes, transfers, and scanner errors.
Does offline check-in prevent duplicate entry across several entrances?
Not automatically. Disconnected devices may not share state instantly. Ask the vendor to explain and demonstrate the precise conflict behavior before planning for it.
Should a small event use QR check-in?
Not always. A simple list can be quicker for a small, stable group. QR check-in becomes more valuable with volume, multiple staff, repeat events, access rules, or a need for reliable attendance data.
What should the door team do when the scan fails?
Follow a written escalation: recheck identity and event/date, search the order if permitted, involve a supervisor, and record the final decision. Never improvise a financial policy under queue pressure.
What should be reconciled after the event?
Compare orders, refunds, transfers, guest entries, check-ins, capacity, and any walk-in sales. Investigate differences while staff memory is fresh.
Run the entrance rehearsal with the staff and phones assigned to the event. Record unresolved cases before opening sales that depend on a particular access rule. The mobile app checklist covers roles and device preparation.