Ticket
One issued instance of admission, with its own identifier, a price paid or waived at issue, and a validity window. A ticket is the unit that is scanned, marked used, revoked, or replaced — not the class it came from and not the batch it was drawn from.
Why it matters in practice. The identifier is what makes a door decision traceable. Without a distinct id per ticket, every scan is a guess and a lost or duplicated ticket can only be handled by reissuing from the top. A ticket is also the thing that stops being a record once it is used: the scan event survives, the admission does not.
Often confused with Ticket type, Will-call, Invoice.
Ticket type
The class a ticket is issued from — general admission, early bird, VIP, staff, complimentary — carrying the price, the validity window, and what it grants access to. Systems often call this a category, and treat the batch as the pool it is drawn from rather than a type in itself.
Why it matters in practice. Types are where pricing and access rules live, so a type defined without a validity window or a named lane produces arguments at the gate rather than before it. Adding a type late also means deciding what happens to tickets already issued under the old shape, which is a change to live inventory rather than a new row.
Often confused with Ticket, Comp ticket, Gross margin.
Check-in
The moment a ticket is presented at a gate or zone and a decision is recorded: accepted, rejected, or overridden. A single-entry ticket is marked used at that point; a multi-entry ticket has an entry count decremented, and entry and exit can be tracked as times rather than as a flag.
Why it matters in practice. Check-in is an access event, not an attendance record. It answers whether the door opened, and it carries the identity of the staff member and the device that made the call. It does not record how long someone stayed, what they did, or whether they came back — and it is not a timesheet.
Often confused with QR validation, No-show, PIN access.
QR validation
Checking a presented code against the ticket record and returning an explicit outcome rather than a yes or no: valid, duplicate, expired, invalid, or wrong-group. The code carries a signed payload, and the decision is made against the record the code points to, not against anything typed in at the gate.
Why it matters in practice. Explicit outcomes are what let a gate work without a supervisor for every decision — the person scanning reads a reason, not a judgement call. The limit worth stating plainly: validation checks a code, not a person, so a photo of a valid code on another phone presents as valid until it is scanned.
Often confused with Check-in, Duplicate scan, Audit trail.
Duplicate scan
A second presentation of a ticket that has already been used, blocked with a clear visual and audible signal on the scanner so the outcome does not depend on the operator recognising the person. Where a ticket allows multiple entries, the limit is an entry count rather than a one-time block.
Why it matters in practice. Duplicate blocking is a throughput feature as much as a control: a lane that stops on every repeat turn becomes the slowest gate in the venue, and staff start overriding it. It only catches a duplicate once every device has seen the ticket — a scan made offline by another device is a duplicate the blocking has not seen yet.
Often confused with QR validation, Offline queue, No-show.
Offline queue
Scans taken while a device has no connection, held on the device and replayed automatically when it reconnects. The scanner still has to say something at the gate, so the on-device answer is a provisional one and the authoritative decision lands later.
Why it matters in practice. A queue is designed deferral, not magic. Duplicate detection, capacity limits, and validity windows are all evaluated against state the device cannot see while it is offline, so a queue shifts the risk from a stalled gate to a reconciliation task afterwards. Queued scans should be flushed before a device is handed to the next shift, and a device with a large pending count is a device whose last hours of decisions are unconfirmed.
Often confused with Duplicate scan, QR validation, Post-event reconciliation.
Will-call
The counter practice of holding admission for a named person and releasing it at the door on the day. In a system it is not a separate object so much as a manually issued ticket created at the counter with staff approval, kept against the person collecting it rather than sold in advance.
Why it matters in practice. It is the point in the evening where a paper list most often replaces the record, and a paper list is what the gate then has to trust. Handing over a pre-issued ticket instead keeps the entry attributable to a person and a device; writing the name on a list keeps it attributable to whoever read the list out.
Often confused with Ticket, Comp ticket, Threshold approval.
Gate capacity
The limit on how many people may be inside a venue, a zone, or a ride group at once, enforced against the live entry and exit counts rather than against the number of tickets sold. Each device can be assigned to a gate, and entry counts are read per gate, per group, and per interval.
Why it matters in practice. The limit the system enforces is the one it can count, and a live count is only as good as the exit scans behind it. Selling fewer tickets than the capacity does not fill the venue, and selling more does not breach it — so capacity planning, ticket volume, and the physical layout have to be agreed before the batch is loaded, not discovered at the gate.
Often confused with Check-in, Stock on hand, Permission scope.
Comp ticket
A ticket issued with no value attached, released through manager approval rather than sold at a counter. It behaves like any other ticket at the gate — it scans, it can be single or multi-entry, and it can be revoked — while contributing nothing to revenue.
Why it matters in practice. Zero value and manager approval are the whole point, so a comp should be the harder path rather than a discount applied afterwards. Two decisions have to be made explicitly: whether comps are distinguishable in the scan record, and whether a revoked comp still needs an entry and exit scan, since a zero-value ticket that never enters the count will quietly distort a capacity limit.
Often confused with Will-call, Threshold approval, Separation of duties.
Ticket transfer
Moving an issued ticket from one holder to another, which changes who is entitled to enter without changing the ticket count. Handing a ticket to a self-serve purchaser is a different thing entirely and is not part of the operator record.
Why it matters in practice. A transfer that only exists as a conversation is a duplicate entry waiting to happen: the original holder and the new one both arrive with a code that validates. Where transfer is not yet available as a self-serve action, the honest version is a staff operation — revoke with a recorded reason and reissue to the named person — which is slower than a transfer and leaves a trail that a handover did not.
Often confused with Ticket, Comp ticket, Override.
No-show
A ticket that was issued or sold and never presented. It is an absence observed in hindsight, not an event the system records: nothing happens at the gate, because nobody comes to the gate.
Why it matters in practice. A no-show is the difference between tickets issued, tickets scanned, and tickets still held, and it is a real cost that is invisible in every entry count. It is also not a refund question by default — the money was collected against an admission that was not used, and whether that becomes a credit, a roll-forward, or a lost sale is a commercial decision rather than a system fact.
Often confused with Comp ticket, Refund, Post-event reconciliation.
Post-event reconciliation
The comparison after the doors close that puts the issued side and the door side of the event next to each other: tickets issued per batch, scans per device and per gate, rejections by reason, staff activity, and unsent or duplicate entries. Scan summaries, hourly scans, device reports, and CSV exports are the inputs.
Why it matters in practice. This is currently a comparison a person performs, not a report that closes itself. The gap between issued and scanned is where no-shows, comps, revocations, and unreconciled offline scans all land together, and it is not attributable from the entry count alone — so the practical output is a short list of questions to answer, not a settled number.
Often confused with No-show, Offline queue, Day-end close.