[ LIVE_EVENTS ]

Event Ticketing Operations Console

2026Internal Tools & AdminIn-depth

What it is

Everything an events team does between selling a ticket and letting someone through the door.

Client work is shown without identifying imagery

[ THE_PROBLEM ]

Why this existed

Everything a ticketing business does between selling a ticket and admitting someone is operations — and it is invisible in most ticketing products, so teams end up querying the database at the door.

[ WHAT_WE_BUILT ]

What we built

Event creation with tiers, images and attendee lists; ticket validation and verification with QR scanning, plus manual ticket issuance with retry for when the scan fails at the gate; refunds and per-order refund handling; a moderation queue over user posts, reports and users; vendor management and vendor post approval; ad campaign management; social review verification; admin user management with roles; and image upload with server-side compression. Built as a separate Next.js application talking to the same backend as the consumer app, with JWT-authenticated admin sessions distinct from customer auth.

Event creation with tiers, images and attendee lists
Ticket validation and verification with QR scanning
Manual ticket issuance with retry for failed scans at the gate
Refunds and per-order refund handling
Moderation queue over posts, reports and users
Vendor management with post approval
Ad campaign management and social review verification
Admin user management with roles
Image upload with server-side compression
JWT-authenticated admin sessions separate from customer auth

[ HOW_IT_IS_USED ]

How a company uses it

The operations half of any ticketed business. Door staff, support, finance and moderation each get their surface without anyone touching the database.

Built with

Next.jsConvexJWTZXingSharp

[ COMMON_QUESTIONS ]

Questions clients ask

Why is manual ticket issuance a feature?

Because scanners fail and phones die, and there is a queue outside. An operations console that assumes the happy path gets abandoned the first time it does not work at the door. The retry path exists because the failure is routine, not exceptional.

Why separate admin authentication from customer authentication?

Different threat models and different lifecycles. Staff accounts need role granularity, revocation and session control that customer accounts do not, and keeping them in separate systems means a compromise of one does not automatically become a compromise of the other.

Can it work with our existing ticketing backend?

The console is a separate application talking to a shared backend, which is deliberately how it was built. Pointing it at a different backend is an integration project rather than a rewrite, provided that backend exposes the necessary operations.

[ RELATED_WORK ]