QR scanner deployment checklist, from gate plan to reconciliation.
Thirty rows across the deployment, not just the morning of: gate count and device allocation, charge and spares, who operates which device and who may override, the network plan and the offline policy, duplicate handling, and the reconciliation of tickets issued against tickets attended afterwards. Every row has a tick box, an owner, and a date. Copy it as CSV.
The template, filled with an example
The example is a fictional single-venue conference with 3 gates, 6 devices, and 2 spares across a two-and-a-half-hour entry window. The tick boxes are left empty, because the point of the document is the rows you are being asked to close out.
Illustrative example only. The event, venue, gates, devices, people, and dates are invented for this page. No throughput, capacity, scan rate, or attendance figure is claimed anywhere on it — how many devices you need is a separate calculation with its own assumptions, and a checklist is the wrong place to invent one.
Event header
- Event
- Sample Annual Conference (example)
- Venue
- Sample Convention Hall, Bengaluru (example)
- Event date
- 12-12-2026
- Entry window
- 09:00 to 11:30
- Gates
- 3
- Scanner devices
- 6 — 2 per gate
- Spare devices
- 2 held by the gate supervisor
- Ticket types
- Early bird, Standard, Student
- Event lead
- Sample Events Lead (example)
- Gate supervisor
- Sample Gate Supervisor (example)
- Escalation contact
- Sample On-call Engineer (example), on the whole entry window
- Venue manager
- Sample Venue Manager (example)
Gates, devices, and charge
| ID | Tick | Item | Owner | When |
|---|---|---|---|---|
| G1 | ☐ | Gate count decided and marked on the venue plan, with the position of each queue | Events lead | Before ticket sales open |
| G2 | ☐ | Devices allocated per gate, and each device assigned to one gate rather than shared | Gate supervisor | At least one week before |
| G3 | ☐ | Each device registered and approved against this event, with a staff identity attached to it | Admin | At least one week before |
| G4 | ☐ | Every device tested on this event's actual tickets, online, before the day | Gate supervisor | Three days before |
| G5 | ☐ | Full charge confirmed on every device, and chargers or power banks available per gate | Gate supervisor | Night before, and again at 09:00 |
| G6 | ☐ | Spares identified, charged, and held by one named person | Gate supervisor | Night before |
| G7 | ☐ | Device collection and return agreed in writing, with a named person accountable | Events lead | Before the day |
Staff and operator roles
| ID | Tick | Item | Owner | When |
|---|---|---|---|---|
| S1 | ☐ | One operator named per device, with a deputy for the roles that cannot be delegated | Gate supervisor | Before the day |
| S2 | ☐ | Override authority named, with one deputy, and both briefed on when to use it | Venue manager | Before the day |
| S3 | ☐ | Gate staff briefed on the distinct outcome for each case: duplicate, expired, revoked, wrong event, unknown code | Gate supervisor | Day before |
| S4 | ☐ | Everyone briefed that a duplicate is refused by default, and that an override is recorded | Gate supervisor | Day before |
| S5 | ☐ | A short gate brief scheduled before doors open, not during the queue | Gate supervisor | 09:45 on the day |
| S6 | ☐ | Finance contact named for money questions during and after the event | Events lead | Before the day |
Network and offline policy
| ID | Tick | Item | Owner | When |
|---|---|---|---|---|
| N1 | ☐ | Venue network checked, and the weak spots identified before the day rather than during it | Events lead | Two weeks before |
| N2 | ☐ | Offline policy agreed: how long a device keeps validating without a connection | Events lead | One week before |
| N3 | ☐ | Decided and written down what happens to a scan that cannot be confirmed at the moment | Events lead | One week before |
| N4 | ☐ | Offline behaviour tested on your actual scanners, Android version, and venue connectivity | Admin | During rollout, not on the day |
| N5 | ☐ | Sync recovery time agreed — when queued scans are reconciled once a connection returns | Events lead | One week before |
| N6 | ☐ | Venue clock accuracy checked on every device, so scan order means what you think it means | Gate supervisor | Night before |
Duplicate handling, exceptions, and spares
| ID | Tick | Item | Owner | When |
|---|---|---|---|---|
| D1 | ☐ | Duplicate handling decided in writing before doors open, not at the gate | Events lead | One week before |
| D2 | ☐ | Named person who can override, and the record that an override leaves behind | Venue manager | Before the day |
| D3 | ☐ | Comps and exemptions recorded as a decision someone made, not as a missing scan | Events lead | Day of |
| D4 | ☐ | Spares reachable by one person during the window, without leaving a gate unmanned | Gate supervisor | Day of |
| D5 | ☐ | What happens if a device fails mid-window: who swaps it, and who records the gap | Gate supervisor | Day of |
| D6 | ☐ | Every manual entry recorded with a reason, at the time it happens | Gate supervisor | Throughout |
After the event
| ID | Tick | Item | Owner | When |
|---|---|---|---|---|
| R1 | ☐ | Ticket batches issued recorded with their known counts, so a missing ticket has a scope | Events lead | Before the day |
| R2 | ☐ | Issued and sold read against scanned, by ticket type | Events lead | Next day |
| R3 | ☐ | Collected value read against sold, and what is still to settle is listed | Finance | After settlement |
| R4 | ☐ | Overrides, refusals, and exemptions listed by gate, with the reason for each | Gate supervisor | Next day |
| R5 | ☐ | Devices collected back, counted, and signed in | Gate supervisor | End of the night |
| R6 | ☐ | Written down while it is specific: what should change for the next event | Events lead | Within two days |
How to read the tick column
- ☐
- Not yet done
- ☑
- Done, and logged by the owner of that row
- N/A
- Not applicable to this event — write why in the owner column
QR scanner deployment checklist (CSV — illustrative example data) Field,Value Event,Sample Annual Conference (example) Venue,"Sample Convention Hall, Bengaluru (example)" Event date,12-12-2026 Entry window,09:00 to 11:30 Gates,3 Scanner devices,6 — 2 per gate Spare devices,2 held by the gate supervisor Ticket types,"Early bird, Standard, Student" Event lead,Sample Events Lead (example) Gate supervisor,Sample Gate Supervisor (example) Escalation contact,"Sample On-call Engineer (example), on the whole entry window" Venue manager,Sample Venue Manager (example) Section,ID,Tick,Item,Owner,When Gates and devices,G1,☐,"Gate count decided and marked on the venue plan, with the position of each queue",Events lead,Before ticket sales open Gates and devices,G2,☐,"Devices allocated per gate, and each device assigned to one gate rather than shared",Gate supervisor,At least one week before Gates and devices,G3,☐,"Each device registered and approved against this event, with a staff identity attached to it",Admin,At least one week before Gates and devices,G4,☐,"Every device tested on this event's actual tickets, online, before the day",Gate supervisor,Three days before Gates and devices,G5,☐,"Full charge confirmed on every device, and chargers or power banks available per gate",Gate supervisor,"Night before, and again at 09:00" Gates and devices,G6,☐,"Spares identified, charged, and held by one named person",Gate supervisor,Night before Gates and devices,G7,☐,"Device collection and return agreed in writing, with a named person accountable",Events lead,Before the day Staff and operator roles,S1,☐,"One operator named per device, with a deputy for the roles that cannot be delegated",Gate supervisor,Before the day Staff and operator roles,S2,☐,"Override authority named, with one deputy, and both briefed on when to use it",Venue manager,Before the day Staff and operator roles,S3,☐,"Gate staff briefed on the distinct outcome for each case: duplicate, expired, revoked, wrong event, unknown code",Gate supervisor,Day before Staff and operator roles,S4,☐,"Everyone briefed that a duplicate is refused by default, and that an override is recorded",Gate supervisor,Day before Staff and operator roles,S5,☐,"A short gate brief scheduled before doors open, not during the queue",Gate supervisor,09:45 on the day Staff and operator roles,S6,☐,Finance contact named for money questions during and after the event,Events lead,Before the day Network and offline policy,N1,☐,"Venue network checked, and the weak spots identified before the day rather than during it",Events lead,Two weeks before Network and offline policy,N2,☐,Offline policy agreed: how long a device keeps validating without a connection,Events lead,One week before Network and offline policy,N3,☐,Decided and written down what happens to a scan that cannot be confirmed at the moment,Events lead,One week before Network and offline policy,N4,☐,"Offline behaviour tested on your actual scanners, Android version, and venue connectivity",Admin,"During rollout, not on the day" Network and offline policy,N5,☐,Sync recovery time agreed — when queued scans are reconciled once a connection returns,Events lead,One week before Network and offline policy,N6,☐,"Venue clock accuracy checked on every device, so scan order means what you think it means",Gate supervisor,Night before Duplicate handling and spares,D1,☐,"Duplicate handling decided in writing before doors open, not at the gate",Events lead,One week before Duplicate handling and spares,D2,☐,"Named person who can override, and the record that an override leaves behind",Venue manager,Before the day Duplicate handling and spares,D3,☐,"Comps and exemptions recorded as a decision someone made, not as a missing scan",Events lead,Day of Duplicate handling and spares,D4,☐,"Spares reachable by one person during the window, without leaving a gate unmanned",Gate supervisor,Day of Duplicate handling and spares,D5,☐,"What happens if a device fails mid-window: who swaps it, and who records the gap",Gate supervisor,Day of Duplicate handling and spares,D6,☐,"Every manual entry recorded with a reason, at the time it happens",Gate supervisor,Throughout Post-event reconciliation,R1,☐,"Ticket batches issued recorded with their known counts, so a missing ticket has a scope",Events lead,Before the day Post-event reconciliation,R2,☐,"Issued and sold read against scanned, by ticket type",Events lead,Next day Post-event reconciliation,R3,☐,"Collected value read against sold, and what is still to settle is listed",Finance,After settlement Post-event reconciliation,R4,☐,"Overrides, refusals, and exemptions listed by gate, with the reason for each",Gate supervisor,Next day Post-event reconciliation,R5,☐,"Devices collected back, counted, and signed in",Gate supervisor,End of the night Post-event reconciliation,R6,☐,Written down while it is specific: what should change for the next event,Events lead,Within two days
Four rows carry most of the value, and all four sit before the event rather than on it: devices registered and approved against the event with a staff identity attached (G3), the duplicate and override policy written down in advance (D1, D2), offline behaviour tested on your actual hardware during setup (N4), and ticket batches issued with known counts (R1). Each one is a decision that is cheap in advance and expensive at the gate.
How to fill it in
Five steps, starting when the event is created rather than the week of it.
Start it when the event is created, not in the entry week
Rows N1, N2, and R1 are due weeks ahead of the date, because gate allocation, offline policy, and batch issuance are decisions rather than errands. A checklist written in the entry week is a checklist of things that are already too late.
Name a person per device, and a deputy per role
Not a team, not “gate staff”. The example gives every row an owner and, for the roles that cannot be handed to whoever is nearest, a deputy — because an unattributed operator is what makes a scan record unable to settle a question.
Decide the duplicate and override rules in writing, in advance
Before doors open, not during. Rows D1 and D2 exist so that the decision has a date on it and a name attached to it, and so a supervisor overriding a scan is a recorded outcome rather than a private favour.
Test offline behaviour on your own hardware, during setup
Row N4 is deliberately not a day-of task. Confirming how your scanners behave without a connection is part of setting the event up, with your devices and your venue — not something to find out with a queue in front of you.
Reconcile the next day, while the logs are still fresh
Issued against scanned by ticket type, and sold against collected once settlement lands. Then write down what should change while it is still specific. This is the stage people skip, and it is the one that makes the next event better.
When to use this, and when to stop
Entry operations have to survive people you have not met. A written list is the minimum, and it is a long way from the maximum.
When this template is the right tool
- You run events at a venue with more than one gate, or more than one person scanning.
- You sell entry in batches and want to know which batch a missing ticket came from.
- You have had a gate argument about a duplicate, and the resolution depended on who was standing there.
- You take money on site and the sold, scanned, and collected figures are reconciled by different people.
When you have outgrown it
- The gate runs on whoever is there, with the rules decided at the moment they are asked.
- Ticket sales, attendance, and money are three spreadsheets reconciled once, weeks later.
- Device issues are discovered during the entry window, and the queue is how you find out.
- Override decisions are made on the day and cannot be reviewed afterwards by anyone.
The same process in NoxOrigin
Most of this checklist exists because the decision is usually made late. In the Events area, the event is created with its dates, venue, gates, and ticket types; tickets are issued in batches with a known count and a known issue, so a missing ticket is a question with an answerable scope; the credential is a signed QR ticket that carries its own validity rather than referring back to a live lookup on every scan. Each scanner device is registered and approved against the event and assigned to a gate with a staff identity attached, because an unattributed scanner produces scan logs that cannot settle an argument. A second scan of the same ticket is refused by default, and exceptions — wrong ticket type, wrong gate, unknown code, supervisor override — are distinct recorded results written to an audit trail. Where connectivity drops, validation continues against the credential and unconfirmed results are queued for sync recovery; how that behaves on your specific scanners, Android version, and venue connectivity is validated during rollout rather than promised as a universal guarantee. Afterwards, issued and sold are read against scanned, and collected value against sold, so unsold tickets, admitted entries without a scan, exemptions, and payments still to settle are line items with reasons rather than a disagreement about which number to believe. It is entry operations for teams running their own events — not a public ticketing marketplace and not a self-service portal.
- Events & Ticketing — scoped Nox-Tickets deploymentEvent setup, ticket batch issuance, signed QR credentials, offline-capable validation with queued sync, gate and device assignment, recorded exceptions, and post-event reconciliation.
- QR ticket scanning softwareValidation, scanner device management, and entry control for events and venues.
- Offline ticket scanningHow offline scans queue and recover — the failure mode the pre-event device test in this checklist exists to catch.
- QR scanning capacity calculatorWork out a scanner count from observed throughput and your own peak entry window, rather than guessing at the gate.
- Event check-in operating runbookThe same ground written as a runbook: gates, devices, operators, outcomes, offline policy, escalation, and post-event review.
- Event entry checklistThe wider entry operation this deployment checklist sits inside, from ticket batches through to the reconciliation.
- Day-end closing sheetIf entry is also sold at the door, the on-site money needs the same expected-against-counted treatment the next morning.
QR scanner deployment questions
How many devices do I need per gate?
That is a capacity question with its own assumptions, and it is not answered on this page — the number depends on your arrival curve, your entry window, and what a device achieves in your hands at your venue. There is a separate capacity calculator linked below for the estimate. What this checklist does is make you allocate devices per gate deliberately and name a person accountable for each one, rather than discovering on the day that the sixth phone in a pocket was doing all the work.
What should the offline policy actually say?
Three things: how long a device keeps validating when the connection drops, what happens to a scan that cannot be confirmed at the moment it is taken, and who can authorise an exception. Writing those down beforehand is what stops each gate improvising a different rule, and a policy invented at the door is a policy applied inconsistently — which is the version that ends in an argument with a guest holding a valid ticket.
How should duplicate scans be handled?
Refused by default, recorded as a distinct outcome rather than a generic failure, with a named supervisor able to override and that override written to the record. The example makes both the policy and the override holder explicit line items, because the override is the decision that gets argued about later and it needs to be attributable to a person.
Does this template promise the gate will work if the internet goes down?
No, and it should not be read that way. Validation runs against a signed credential rather than a live lookup on every scan, and anything unconfirmed is queued for sync recovery once a connection returns — but how that behaves on your scanners, your Android version, your camera performance, and your venue connectivity is confirmed during rollout, on your actual hardware. That is a narrower and more useful claim than “works offline anywhere”.
What does the post-event reconciliation actually catch?
The gap between tickets issued and tickets attended, and the gap between value sold and value collected. Unsold tickets, admitted-but-unscanned entries, comps, exemptions, and payments still to settle all show up as specific items with a reason attached, rather than as a vague sense that the evening did not add up. Doing it the next day, before everyone has agreed a version of events, is the version that produces a real answer.
Is this for selling tickets online to the public?
No. This is entry operations for a team running its own events — issuance, credentials, gate control, and reconciliation. It is not a marketplace where anyone can list and sell a ticket, and it is not a self-service portal for the public to buy from. If you need public e-commerce, that is a different requirement and worth saying so before anyone builds a plan around this page.
Decide the gate rules before the queue decides them for you.
Duplicate handling, override authority, and the offline policy are cheap in advance and expensive at the door.