Event entry checklist, from batch setup to reconciliation.
The whole entry operation as one list: tickets and batches, device testing, the offline policy, the staff briefing on what a duplicate scan means, the day-of gate readiness with named override authority, and the reconciliation of tickets issued against tickets attended afterwards. Copy it as CSV and run the next event from it.
The template, filled with an example
The example is a fictional conference with three gates and six devices, over a two-and-a-half-hour entry window. The dates and times are the shape of the thing — the list is the part you keep.
Illustrative example only. The event, venue, gates, devices, people, and dates are invented for this page, and no attendance, revenue, or throughput figure is claimed anywhere. Gate planning capacity is a separate calculation with its own assumptions.
Event header
- Event
- Sample Annual Conference (example)
- Venue
- Sample Convention Hall (example)
- Event date
- 12-12-2026
- Entry window
- 09:00 to 11:30
- Gates
- 3
- Scanner devices
- 6
- Ticket types
- Early bird, Standard, Student
- Events lead
- Sample Events Lead (example)
- Gate supervisor
- Sample Gate Supervisor (example)
- Venue contact
- Sample Venue Manager (example)
Before the event
| ID | Task | Owner | Due | Status |
|---|---|---|---|---|
| P1 | Publish the ticket batches and record the batch references issued | Events lead | 20-11-2026 | Not started |
| P2 | Confirm ticket types, prices, and the tax treatment with the accountant | Events lead | 20-11-2026 | Not started |
| P3 | Agree the offline policy and the connectivity fallback for the venue | Events lead | 28-11-2026 | Not started |
| P4 | Hand out the scanner devices and record the device list against each gate | Gate supervisor | 05-12-2026 | Not started |
| P5 | Test scanning on every device, both online and offline, and log the result | Gate supervisor | 06-12-2026 | Not started |
| P6 | Brief gate staff on the response for a duplicate, expired, invalid, and revoked ticket | Gate supervisor | 11-12-2026 | Not started |
| P7 | Print gate signage, the gate map, and the escalation contact card | Events lead | 08-12-2026 | Not started |
| P8 | Confirm who holds the override authority, and one deputy for it | Venue manager | 08-12-2026 | Not started |
On the day
| ID | Task | Owner | Due | Status |
|---|---|---|---|---|
| D1 | Check device charge and confirm the device count at each gate | Gate supervisor | 09:00, 12-12-2026 | Not started |
| D2 | Cash float and UPI standee in place at the on-site counter | Counter staff | 09:00, 12-12-2026 | Not started |
| D3 | Test scan once per device, then clear the test entries before the queue starts | Gate supervisor | 09:30, 12-12-2026 | Not started |
| D4 | Confirm the escalation contact is on call for the whole entry window | Events lead | 09:00, 12-12-2026 | Not started |
| D5 | Record every manual entry with a reason, at the time it happens | Gate supervisor | Through the entry window | Not started |
| D6 | Hold a short gate brief before doors open: who decides, and who is called | Gate supervisor | 09:45, 12-12-2026 | Not started |
After the event
| ID | Task | Owner | Due | Status |
|---|---|---|---|---|
| E1 | Reconcile tickets issued against tickets attended, by ticket type | Events lead | 13-12-2026 | Not started |
| E2 | Record no-shows, overrides, and rejection reasons by gate | Gate supervisor | 13-12-2026 | Not started |
| E3 | Close out the scan logs and note any device that failed or ran out of charge | Gate supervisor | 13-12-2026 | Not started |
| E4 | Reconcile on-site collections against the counter and the settlements | Accounts | 15-12-2026 | Not started |
| E5 | Collect the devices, confirm the count, and sign them back in | Gate supervisor | 13-12-2026 | Not started |
| E6 | Write down what should change for the next event, while it is still specific | Events lead | 16-12-2026 | Not started |
Status key
- Not started
- Not begun
- In progress
- Started
- Done
- Completed and logged
- Blocked
- Stalled, with the blocker named after it
Event entry checklist (CSV — illustrative example data) Field,Value Event,Sample Annual Conference (example) Venue,Sample Convention Hall (example) Event date,12-12-2026 Entry window,09:00 to 11:30 Gates,3 Scanner devices,6 Ticket types,"Early bird, Standard, Student" Events lead,Sample Events Lead (example) Gate supervisor,Sample Gate Supervisor (example) Venue contact,Sample Venue Manager (example) Stage,ID,Task,Owner,Due,Status Before the event,P1,Publish the ticket batches and record the batch references issued,Events lead,20-11-2026,Not started Before the event,P2,"Confirm ticket types, prices, and the tax treatment with the accountant",Events lead,20-11-2026,Not started Before the event,P3,Agree the offline policy and the connectivity fallback for the venue,Events lead,28-11-2026,Not started Before the event,P4,Hand out the scanner devices and record the device list against each gate,Gate supervisor,05-12-2026,Not started Before the event,P5,"Test scanning on every device, both online and offline, and log the result",Gate supervisor,06-12-2026,Not started Before the event,P6,"Brief gate staff on the response for a duplicate, expired, invalid, and revoked ticket",Gate supervisor,11-12-2026,Not started Before the event,P7,"Print gate signage, the gate map, and the escalation contact card",Events lead,08-12-2026,Not started Before the event,P8,"Confirm who holds the override authority, and one deputy for it",Venue manager,08-12-2026,Not started On the day,D1,Check device charge and confirm the device count at each gate,Gate supervisor,"09:00, 12-12-2026",Not started On the day,D2,Cash float and UPI standee in place at the on-site counter,Counter staff,"09:00, 12-12-2026",Not started On the day,D3,"Test scan once per device, then clear the test entries before the queue starts",Gate supervisor,"09:30, 12-12-2026",Not started On the day,D4,Confirm the escalation contact is on call for the whole entry window,Events lead,"09:00, 12-12-2026",Not started On the day,D5,"Record every manual entry with a reason, at the time it happens",Gate supervisor,Through the entry window,Not started On the day,D6,"Hold a short gate brief before doors open: who decides, and who is called",Gate supervisor,"09:45, 12-12-2026",Not started After the event,E1,"Reconcile tickets issued against tickets attended, by ticket type",Events lead,13-12-2026,Not started After the event,E2,"Record no-shows, overrides, and rejection reasons by gate",Gate supervisor,13-12-2026,Not started After the event,E3,Close out the scan logs and note any device that failed or ran out of charge,Gate supervisor,13-12-2026,Not started After the event,E4,Reconcile on-site collections against the counter and the settlements,Accounts,15-12-2026,Not started After the event,E5,"Collect the devices, confirm the count, and sign them back in",Gate supervisor,13-12-2026,Not started After the event,E6,"Write down what should change for the next event, while it is still specific",Events lead,16-12-2026,Not started
The device test and the override authority are the two rows most often dropped, and they are the two that cause the problems that cannot be fixed while a queue is waiting. Both sit in the pre-event stage on purpose.
How to fill it in
Four steps, starting when the tickets are published rather than the week of the event.
Start it when the tickets go on sale
The list exists to catch things early, and P1 and P2 on the example are due on the day the batches are published. A checklist written the week of the event is a checklist of things that are already too late.
Name an owner per row, never a team
“Gate team” is not an owner. One person who is answerable for each row is what makes the list usable on a busy morning, and one deputy for the roles that cannot be delegated to whoever is nearest.
Make the day-of rows time-anchored
09:00, 09:30, 09:45. A row with a time attached gets done at that time; a row that says “before the event” gets done whenever somebody remembers, which on the day is usually during the queue.
Do the reconciliation the next day
Issued against attended, by ticket type, plus overrides and rejections by gate. Same day, while it is fresh. 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 are the clearest case of a routine that has 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 are still learning what fails on the day, and the failures are not the ones you expected.
- You sell tickets, take money on site, and the two are reconciled by different people.
- You want the same entry routine at every event rather than a new improvisation each time.
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 that are only reconciled once, weeks later.
- Device issues are discovered during the entry window, and the queue is the way you find out.
- Override decisions are made on the day and cannot be reviewed afterwards by anyone.
The same process in NoxOrigin
The checklist is a plan. In NoxOrigin the same work is enforced by the system: ticket batches are issued with signed QR credentials, every scan produces a defined outcome against a live or queued dataset, duplicate and revoked scans are visible as outcomes rather than as a queue, overrides are recorded with the operator who made them, and devices can be handed out and signed back in against a device list. Post-event reconciliation compares issued against attended and no-shows from the records rather than from a count somebody types in afterwards.
- Events & Ticketing — scoped Nox-Tickets deploymentEvent setup, ticket batch issuance, signed QR credentials, offline-capable scanning, multi-gate operations, and post-event reconciliation.
- Nox-TicketsThe scoped dedicated deployment, retained where QR validation, scanner devices, and gate operations are run as their own system.
- Event check-in operating runbookGates, devices, operators, validation outcomes, offline policy, escalation, and post-event review, written as a runbook.
- QR ticket scanning softwareValidation, device management, and entry control for events and venues.
- Offline ticket scanningHow offline scans queue, synchronise, and affect entry operations — the failure mode the pre-event device test is aimed at.
- Day-end closing sheetFor the on-site counter, if the event takes money at the door as well as tickets.
Event entry checklist questions
Why test the scanners before the event rather than at the gate?
Because the entry window is the one part of an event that cannot be paused. A device that is dead, uncharged, or holding stale data is discovered in front of a queue. The example tests every device online and offline days in advance and logs the result, so a failure at 09:00 on the day is a known, replaceable problem rather than an incident.
What does the offline policy actually decide?
How long a device keeps working without a connection, whether a scan is accepted locally and reconciled later or refused outright, and who authorises an exception. Deciding it before the event is what stops each gate from improvising a different rule, which is the version that ends in an argument at the door.
How should duplicates and invalid tickets be handled at the gate?
With a distinct, agreed response for each case — a duplicate, an expired ticket, a revoked ticket, and a ticket for the wrong event — and a named person who can override. The example makes the override authority an explicit line item with a named holder and a deputy, because the alternative is a queue stopping while somebody looks for whoever is in charge.
What does the post-event reconciliation actually catch?
The gap between tickets issued and tickets attended, which is where no-shows, overrides, and mis-scans appear. It also confirms that the devices came back and that the on-site money matches the counter. Doing it the next day, while the logs are still fresh and before the details have been agreed to by everyone involved, is the version that produces a real answer.
Run the gate from a plan, not from memory.
If the rules at the door are decided on the day, the queue is where you find out that they were never really agreed.