Before opening the doors, scan the same test ticket on the two phones your staff will use. Repeat with one phone disconnected, then reconnect it and inspect the result. That test reveals what the team can rely on when the venue network drops.
Also test a cancelled ticket and a guest whose name has changed. Write down what the scanner shows and who resolves each exception.
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 cancelled 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 cancelled.
- 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 capability needs precise questions
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 synchronise later. It may not be able to know that another disconnected entrance just scanned the same ticket.
Ask the vendor:
- What data is available without a connection?
- How recently must it be downloaded or synchronised?
- Can several disconnected devices prevent duplicates in real time?
- What happens if two devices accept the same ticket?
- Who resolves a conflict after reconnection?
- Are capacity and sales figures live, delayed, or unavailable?
Do not claim offline multi-device protection in your event plan until the vendor demonstrates this exact configuration with your devices.
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 behaviour, and failure path.
Gomry’s API introduction publicly documents organisation-scoped API keys and resources including events, attendees, and ticket classes. Read the current API introduction. It does not, by itself, establish a particular scan event or webhook contract. Get specific documentation before designing an integration around one.
Using the Gomry scanner
Gomry's Scanning page, checked on 14 September 2026, describes iOS and Android apps, offline scanning and multi-scanner synchronization. These capabilities need separate tests: local scanning without a network, and shared status between connected devices.
Do not assume two disconnected phones can detect each other's new scans. Check the cached data, reconnection behaviour and duplicate resolution with your event's devices. Also inspect the fields actually shown to the entry role; membership-tier display should not be assumed.
The documented API can provide attendee information for reporting. The current webhook list does not include a scan event, so use the API and webhook contract to design any attendance sync.
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 behaviour 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.