Event Ticketing & Box Office Planner

The problem

Ticketing looks like ecommerce until the doors open, and that is why builds made with AI tools fail at the worst moment. Your agent ships an events page, a checkout and a QR code in an email. The demo is convincing: pick a night, pay, receive a ticket. Every click the founder tries works.

What is missing is dated inventory. A ticket is no ordinary product with a stock count. It is admission to one occurrence, and the same seat sold twice is a person turned away at the door in front of a queue. Capacity must be decided in the same transaction that takes the money, or two buyers at the same moment both get a confirmation. Generic builds almost always read availability first and write the order second. The oversell happens in the gap between those two statements.

The second failure comes after the sale. Someone needs to move a ticket to another night, refund one seat of four, resend a lost email, or reissue a credential the buyer forwarded to a friend. Each of those must change the money, the inventory and the credential together, and the old barcode must stop working. Builds that treat orders as receipts that never change cannot do any of it, so the box office ends up editing the database by hand on show night.

Then there is the door. One real complaint in the research is from a practitioner who scans in one app, copies a number, opens another site and pastes it. That workflow creates an unacceptable queue at the entrance. Scanning must validate and admit in one action. It must tell the difference between valid, duplicate, wrong-occurrence and void. A manual lookup must stay one tap away, for the phone whose screen will not brighten.

What it is built from

The planner is based on a count of 100 products that manage admission inventory themselves. The count is organized into 29 macro capability families, 9 connected lifecycle units, 12 priority screen contracts and 18 micro-UI patterns, with 12 practitioner pain contexts taken from operators who described what made them reject a product.

Your agent cannot rebuild the edge of this cohort, because it is defined by what is left out. A generic event page, a registration form, a payment link, an event calendar or a QR generator is outside this market. An app qualifies only when it manages the ticket or admission inventory. That one rule stops the research from drifting into "events software" in general. The count covers:

• General platforms: Eventbrite, Humanitix, Universe, Ticket Tailor, Quicket.
• Box-office and venue systems: Eventim, Paciolan, Purplepass, TicketSpice.
• Self-hosted or open products: pretix, Hi.Events, Eventyay, Eventcube.

Buyers range from independent theatres and performing-arts organizations to festivals, attractions, timed-entry operators and nonprofits.

The key finding is that what the market documents and what breaks on show night are opposite:

• Payment and tender appear in 96 of 100 products.
• Operational reports: 91.
• Scan and admission: 84.
• Public checkout: 80.
• The order-service workbench where box-office staff spend their time (search, resend, edit, refund, exchange, reissue): only 33 of 100.
• Onsale windows and presale codes: 21.
• Offline scanning with sync and conflict recovery: 7.

The low counts do not mean these matter less. They are rarely documented, and they are the screens that decide whether a venue gets through a sold-out night. A planner that ranked features by how common they are would push every one of them down. This planner ranks them higher because of their lifecycle risk, and the research says so openly.

The research is also honest about what it did not prove:

• Reserved seating is marked QUALIFIED. Editor and box-office workflows have good evidence, but no live buyer seat-conflict flow was tested. So the planner keeps a strong screen contract and does not claim proof against double selection.
• Offline scanning is a branch you must select. It is never a default.
• Settlement and payout are limited to where transaction-level evidence exists.
• Multi-organizer operation stays out of the shared core.

What you get

A planner that treats an event as dated inventory with a lifecycle. A catalog row is not enough. It takes your agent through the business, venue and depth decisions before any code, then holds the build to lifecycle checks:

• The centre a buyer recognizes is fixed. Events → tickets and inventory → box office → orders and patrons → entry → reports. Policy, audit, payment plumbing and integrations support that loop and are never allowed to replace it as the main navigation.
• Capacity is decided where the money is taken. Availability, holds and the sale resolve in one transaction, so two buyers at the same moment cannot both be confirmed into the last seat.
• Every credential can end. Refund, cancellation, postponement, exchange, transfer and reissue must each move money, inventory and ticket validity together. Each must also prove that the replaced barcode is denied at the gate.
• The scan is one action. Validate and admit in the same step, with clear valid / duplicate / wrong-occurrence / void results and a manual recovery path that stays one tap away.
• Depth has limits and is never quietly expanded. Basic is a real general-admission lifecycle. Moderate adds selected venue and box-office depth. Advanced adds only the resilience, distribution, integration, risk or access branches you chose. No depth selects every observed family automatically.

The planner produces a main CLAUDE.md or AGENTS.md and separate spec files. A custody check stops the agent from writing code before the spec is written and locked.