Event Ticketing Software Problems: The 5 That Cost Real Money, and How to Avoid Them

Why does seat inventory get scoped as a seating chart?

Because the map is what everyone sees and the state machine is what nobody asks about. Show a developer your venue plan and they will build a renderer, a click handler and a cart. That is a competent piece of work and it is the biggest scope failure in this category, because a seat is not a shape. It is a record moving through available, held, killed, comped, reserved in cart, sold, transferred and scanned, and every one of those transitions needs an owner, a reason and sometimes an expiry.

Run the awkward parts of your own room past any developer before you sign. Obstructed view seats behind a column. Accessible positions that pair with a companion seat and release together if unsold. A pit configured as standing on Friday and cabaret on Saturday without cloning the event. A balcony killed below a sales threshold because you cannot staff it. Artist holds, production kills and press holds, each with different owners and release rules.

The model that works stores state, reason code, owner and expiry on the seat, versions the configuration per show rather than per room, and enforces the companion constraint rather than relying on somebody remembering it. Licence the rendering if you want, since a map editor is a solved and expensive thing to rebuild, but never let a vendor own the state machine. Your holds, your accessibility rules and your configuration flips live there, and that is the part a platform cannot express for you.

What goes wrong when you migrate seat maps, orders and the fan list?

Plan for a rebuild rather than a migration, because that is what you will get. Seat maps rarely hand over in a usable form and are normally recreated from your venue plans, which is genuinely a good thing: it is the moment you finally model holds, kills and accessible pairing properly instead of inheriting somebody else's approximation.

Order history comes out as an export with an email address, an event name and an amount. What does not come out is the part you actually wanted: the seat, the scan timestamp, the no show, the refund reason, the device. You cannot backfill what was never given to you, so decide early what history is worth importing and accept that scan level behaviour starts from your first show on the new system. That is an argument for moving sooner rather than later.

Then there is identity. The buyer who used one address in 2023 and a variant last Friday is one human, and every platform export treats them as two. Build the person record as the spine of the new system, deduplicating across email, phone and payment fingerprint, and write everything else against it: orders, seats, scans, refunds, bar spend if your point of sale (POS) can feed it. Do not attempt a full cutover in your busiest month. Move a low risk room or a midweek series first, run it for a season alongside the old provider, and graduate the high demand onsales once the queue has been proved under real load.

Why do payment, scanner and point of sale integrations break after launch?

Payment integrations break on retries and duplicates rather than on failures. A customer double taps at 10:00:01, the network stalls, the app resubmits, and without an idempotency key on the payment intent you have charged twice for one seat and created a refund conversation on your busiest day. Design idempotency in from the start rather than adding it after the first incident, and make cart holds expire hard rather than politely.

Scanners break on doors and networks. A venue basement with no signal, a lanyard scanner whose battery dies at half time, two gates scanning the same code within a second. Offline capable native apps are the requirement, and the hard part is not scanning, it is reconciling two devices that both accepted the same ticket while disconnected. Decide the rule before you build: first scan wins, later scans surface to a supervisor, and the record shows both attempts with device and timestamp.

Point of sale and wallet integrations break quietly. Wallet passes stop updating when a show time changes if the pass was issued statically. A Toast or Square feed drifts when someone adds a revenue centre and it lands unmapped, so bar spend attached to your fan records stops growing for that room. Watch the shape of the traffic rather than only the errors: a room that normally produces spend records and produces none for a week is worth a message that day.

What happens when fee display, bot protection and accessible purchase are not covered?

These three get scoped as polish and they are the ones with legal weight. United States rules on unfair or deceptive fees require live event ticket sellers to display the total price including mandatory fees up front, and that obligation follows you whether you sell through a platform or your own software. Building your own actually makes it easier, because your fee engine can calculate the true total at the first price display rather than bolting fees on at checkout. Make a developer show you the pricing display logic, not describe it.

Bot protection is the second. The BOTS Act sits behind it, and the practical requirement is that your onsale is not harvested by scripted buyers in the first ninety seconds. That means device and behavioural signals throttling automated traffic, a waiting room that admits at a rate your inventory service can absorb, and instrumentation that tells you afterwards what happened rather than leaving you to infer it from resale listings.

The accessible purchase path is the third and it is the one platforms do worst. Accessible seating has to be purchasable through the same flow, with the companion seat pairing handled in the interface rather than by phoning the box office. Test it with a screen reader and a keyboard before launch, not after. Separately, keep card data off your own servers: tokenise through your processor with hosted fields so no card number touches your infrastructure, and ask a developer which self assessment scope their architecture places you in and why, before you sign the statement of work.

Should you build custom or configure what you already own?

Stay on the platform if you are under roughly 40,000 tickets a year, your rooms are general admission, you have one legal entity, no co promoter splits and no season or membership product. Eventbrite is genuinely good at that job and you will not beat it on cost. Building at that volume is a vanity project that will consume your operations director for a year.

Before commissioning anything, run a workaround census. Ask your box office manager to list every manual step between an onsale and a settled show. Some of that list will turn out to be configuration nobody has revisited: hold types never set up, fee rules left at defaults, a reserved seating configuration built in a hurry three years ago. Fix what is fixable inside the tool you already pay for, because it is faster and it sharpens the list of what genuinely cannot be expressed.

Build when the remaining list is long and structural. Your annual platform fee spend passes roughly $250,000, meaning software costs less than one season of fees. Your rooms have inventory rules the platform cannot express and your staff has invented manual workarounds that create real exposure. You settle against artists or co promoters and somebody retypes numbers after midnight. You want a membership or season product the platform will not sell. Or you have concluded that the fan graph is the actual asset of a live events business and you do not own yours.

How do hidden costs get into the quote?

Legacy allocation is the quiet budget killer. If a national promoter or a building agreement means part of your inventory stays with an existing provider, you now need a synchronisation path between two systems that disagree about what a ticket is, including how each counts comps. Scope that explicitly with the vendor in the room, or it eats a phase.

Scanner hardware is the second. A quote assuming a phone camera is not the same project as native offline apps on both platforms running against the handheld units you already bought. Name the hardware.

Settlement is the third. A versus deal with a guarantee, a split, an expense pool and a definition of net is business logic rather than a report, and multi entity settlement with tax by jurisdiction is a workstream. Fourth is transfer and resale, which drags in identity verification and fraud handling. Fifth is load testing, which should be specified as a deliverable at multiples of your worst historical peak rather than assumed. Sixth is the parallel season, because running two systems while you graduate rooms costs staff time that belongs in your business case even though no developer quotes it.

What separates a build that works from one that fails here?

The ones that work ship one room. Your own checkout, the inventory state machine, seat maps for that room, a scanner app and the identity spine, live on a midweek show, then a low risk weekend, then the big onsales. The ones that fail attempt every room, settlement, memberships and resale in one release and put a sold out show on a brand new platform first.

Ask what happens at ten in the morning. The answer should include a token based waiting room admitting at a rate your inventory service can absorb, inventory sharded so a hot section does not serialise on a single row lock, idempotency on payment intents, cart holds with hard expiry, and a load test at three times your worst peak run before the first real onsale rather than after it. Vague answers here are disqualifying no matter how good the portfolio looks.

Instrument the fan graph from day one, because it is the asset that survives you changing anything else. Every scan, no show, refund and genre attended should write to the person record, and the queries you want later should be tested early: everyone who attended a show of this type in the last eighteen months, spent above a threshold, within a radius.

Settle ownership before kickoff: full assignment of the code, the repository under your organisation, infrastructure in your own cloud accounts under your billing, and a documented handover. At Digital Heroes the client owns it from the first commit. If a developer will not hand you the keys, you have traded platform lock in for a smaller and worse one.