Event Ticketing Software: What Has to Work on Show Day

What has to work on show day

Six things have to work, and all six are show-day jobs rather than sales jobs. If any one of them fails, the event does not fail gracefully - it fails in public, at the door, with a queue watching.

• Scanning and admission. A scan has to be fast, work without a network, and be idempotent: the same code scanned twice must be refused the second time, and a scan taken while offline must still mark the ticket used once the device reconnects.
• Will-call and box office. Someone arrives without their phone, on the wrong name, with a printed confirmation, or having bought a ticket in the car park two minutes ago. The system needs a lookup that works from any of those and a way to issue a ticket at the door.
• Comps and the guest list. Staff passes, press, sponsors and VIP guests consume capacity without paying for it. They have to count against the same capacity the paid tickets draw on, or your capacity figure is fiction.
• Capacity control and holds. Held or reserved seats released at a stated deadline, plus a live count of who is inside by area, so that security and the floor manager are working from a number rather than an estimate.
• Exchanges, upgrades and refunds at the door. Moving someone from standing to seated, or handling a cancelled night, has to happen in the system that sold the ticket, not in a spreadsheet beside it.
• Walk-up sales. Card-present sales at the venue have to draw on the same inventory as the online store, or the last ten seats get sold twice.

The five scenarios to run in a demo

A feature tour will not show you the failure modes, because the failure modes are about state: which record knows what, and when. Ask to run these five against the system the vendor is actually proposing, in this order.

• Sell online, scan at the door, then look at capacity. One record, or two lists that need reconciling? If the same ticket shows as sold in one place and admitted in another, you have found the whole problem in five minutes.
• Turn the network off. Disconnect the venue wifi, scan twenty tickets, then reconnect. Anything that loses a scan, or admits the same code twice, has failed the test that matters most.
• One buyer, two tickets, one phone. Then transfer one of those tickets to someone else and have both arrive. Who gets admitted, and can the system tell you who holds which ticket?
• Add ten comps and hold ten seats, then try to sell them. A hold that can be sold twice, or a comp that silently consumes paid inventory, means capacity is a number nobody can trust.
• Ask for the report you would close the night on. Tickets sold by channel, fee breakdown, admitted count, refunds and door cash. If producing it takes three exports and a spreadsheet, that is your Tuesday morning, every event, forever.

One record, or two systems and a reconciliation problem

Every failure above has the same root cause: the system that sells and the system that admits hold separate records of the same person and the same seat. A marketplace listing that never writes into your own inventory, or a scanner app keeping its own guest list, creates two truths, and someone has to reconcile them by hand while the queue grows.

The argument for one record is not elegance. It is that capacity only works as a control if the number of tickets sold, the number of tickets held, the number of comps issued and the number of people admitted are all derived from the same inventory. Split that across two systems and the discrepancy is not an edge case, it is the normal state of the event.

It is also why the channel question and the software question are the same question. A marketplace is a demand engine: it owns the audience, sets the fees, and holds the customer relationship. Software you run holds the inventory, the customer records and the follow-up. Selling through both is reasonable, but only one of them should be the record of truth, and it should be the one that also admits people at the door.

ShopDango treats ticketing as one of the things a storefront does rather than a separate system bolted to it: inventory, checkout, customer records and event tickets sit together on a site you brand as your own. That structure is what makes the reconciliation question answerable - one event, one inventory, one record of who holds what.

What changes when one show becomes a series

Most comparisons are made against a single night, and most ticketing problems appear at the third one.

• Per-date inventory and season passes. A series needs inventory per date plus a pass that draws on many of them, which is a subscription shape rather than a one-off sale.
• Several doors, one count. Multiple entrances need admission that reconciles into a single inside count, or nobody can tell you how full the room actually is.
• Door staff turnover. The people scanning on the night are often not the people who set the system up, so roles and permissions matter: who can comp, who can refund, who can issue a ticket at the door, and who is named in the log afterwards.
• Reporting across dates. The useful question after a run of events is which night, which channel and which price band actually sold - and that needs the data in one place from night one.
• Transfers and resale. Once tickets change hands, the record of who holds a ticket becomes the thing your admission depends on, so decide early how transfers are handled and whether they are allowed at all.

Choosing on the admission path, not the feature list

Compare ticketing software by starting at the door and working backwards. A system that admits people cleanly, reconciles at the end of the night without an export, and keeps one record for sold, held, comped and admitted has done the hard part.

Everything else - seat maps, discount codes, promo tiers, analytics dashboards - is useful only after that foundation holds. The demo you should ask for is the network-off scan, the comp, the transfer and the night-close report, run end to end on your own event rather than on the vendor’s demo data.