Events, ticket batches, signed QR tickets, scanner devices, scan logs, and gates — for businesses that sell entry, where the argument after the event is never about whether people came, but about what it was worth. To be explicit about availability, because the rest of this page reads like a product page: Events & Ticketing is not in the current NoxOrigin application and is not included in any NoxOrigin plan. It is part of the architecture and is available as a scoped dedicated or white-label deployment, quoted on its own scope. Everything below describes that deployment. If you need ticketing to come with a plan, it does not.
Entry operations fail at the reconciliation, not at the door. Tickets are issued in a batch from a spreadsheet, scanning is done on whatever phones the crew owns, the connectivity at the gate is whatever it happens to be that evening, and the duplicate-entry rule is decided — if at all — an hour before doors open. Then the organiser asks three questions that nobody can answer from what was used on the night: how many were sold, how many actually came through, and how much was collected. The scan log is a piece of paper, the sold count is in someone’s head, and the money is in a bank deposit slip. Unless all three are kept in one place, the outcome of every event becomes a negotiation about which of those three numbers to believe.
Works with: Customer → Opportunity → Quote → Project → Work → Invoice → Payment
An event is created with its dates, venue, gates, and the ticket types being sold, and tickets are issued in batches rather than as a loose pile of codes. A batch has a known count and a known issue, so when something goes missing you know which issue and how many — not simply that the number is wrong. The credential itself is a signed QR ticket that carries its own validity rather than referring back to a live lookup on every scan.
Scanning does not stop because the venue’s network does. Validation is performed against the signed credential, and anything that cannot be confirmed at the moment is queued for sync recovery once a connection returns. This is the honest description — a resilient offline path, validated during rollout for your specific venue and devices, not a promise that no event will ever be affected by connectivity.
Each device is registered and approved against the event, and assigned to a gate with a staff identity attached to it. Device management is a deliberate setup step rather than a consequence of whoever turned a phone on, because an unattributed scanner produces scan logs that cannot settle an argument. Removal at the end of the night is the same action in reverse, and it is the one teams most often forget.
A second scan of the same ticket is refused by default rather than admitted quietly, and exceptional outcomes — wrong ticket type, wrong gate, unknown code, or a supervisor override — are distinct recorded results rather than a generic failure. Overrides are part of the operational workflow and are recorded in the audit trail, which matters because the override decision is usually the one that gets argued about later.
After the event, the three figures are read against each other: issued and sold against scanned, and collected value against sold. Their differences are the reconciliation — unsold tickets, admitted-but-unscanned entries, exemptions, and payments still to settle. Disagreements show up as a specific line item to explain rather than as a vague feeling that the evening did not add up.
A duplicate entry is blocked by policy rather than by whether the gate staff noticed.
Ticket counts are known by batch, so a missing ticket is a question with an answerable scope.
The gate can keep validating through a connectivity outage instead of turning into a paper list.
Exceptions and overrides are recorded outcomes, so the post-event argument is about facts.
Sold, scanned, and collected become three numbers that can be compared, which is what makes an event accountable.
These are illustrative workflows, not customer results. We do not publish outcome claims without approved customer material.
A guest’s ticket is scanned at the main gate, then their phone is scanned again at the VIP gate because two people from the same booking went through together. The duplicate is blocked and recorded as a refusal, and a supervisor can override it if it is genuinely a second admission. Because the outcome is logged, the count at the end of the night explains itself instead of being quietly corrected by whoever reconciled it.
Connectivity fails while the queue is longest. Scanning continues against the signed credential and the unconfirmed results are queued, then recovered once a connection is available. The evening finishes and the recovery is completed afterwards — which is why the offline behaviour has to be validated against your actual venue and devices during rollout rather than assumed to work anywhere.
A batch of tickets was issued for a walk-up allocation and the closing count is short. Because tickets were issued by batch with a known count, the question is which batches were opened, which were closed, and which were carried to the next event — rather than a general uncertainty about how many exist. The answer takes an afternoon instead of an argument.
Every part of NoxOrigin has awkward edges. Naming them now is cheaper than discovering them in month two.
No. It is not in the current NoxOrigin application and is not included in Starter, Growth or Agency. It is available as a scoped dedicated or white-label deployment, quoted on its own scope. Nox-Tickets is the name that deployment is sold under; it is not an area of NoxOrigin and subscribing to NoxOrigin does not include it.
Validation runs against the signed QR credential and anything unconfirmed is queued for sync recovery, so a network drop does not turn the door into a paper list. How that behaves on your scanners, Android version, and venue connectivity is validated during rollout onboarding.
Duplicate scans are blocked by default and recorded as a distinct outcome. Supervisor overrides are part of the workflow and are written to the audit trail, so an override is always reviewable afterwards.
Yes — multi-gate and multi-venue operations are supported, with gates, devices, and permissions configured per site. Consistent device registration and correct venue time settings are part of that setup.
Scanner devices are registered and approved as part of onboarding, and Android version and camera performance are checked during rollout. We would rather confirm device compatibility for your specific hardware than imply any phone will do the job.
No. It is entry operations for teams running their 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 customer self-service portal.