What a venue ticketing system has to do after the sale

Selling is the easy part

A checkout that takes a card is a solved problem, and every product you are evaluating has one. If you judge a venue ticketing system on its checkout you will pick the one with the nicest screenshots, and then discover in month three that issuing forty comps for a record release takes an hour and a spreadsheet.

What follows is the list of things to make a salesperson actually demonstrate. Not describe. Demonstrate, in the product, while you watch.

Inventory: the three things that are not sales

Capacity is the number everybody trusts until it is wrong at 9pm. Three distinct concepts reduce a room’s sellable inventory, and a system that conflates them will eventually oversell you.

Holds

Inventory removed from sale and not yet given to anybody: production kills, the desk, the promoter’s allocation, the twelve you are keeping for a radio competition. Holds must be releasable back to sale in one action, because at 7pm on the night somebody will ask whether the kills can go on sale, and the answer has to take ten seconds.

Comps

A ticket issued at no charge to a named person. It should scan like any other ticket, it should appear in the door count, and it should cost the venue nothing to issue. Ask that last part directly. Charging a venue a per-ticket fee to give a seat away is common enough that it is worth a specific question.

Guest list

A name at the door with no ticket at all, checked off by a human. This is not a comp, because there is nothing to email and nothing to scan, and it needs to be visible on the same screen the scanner is on. A door person holding a phone in one hand and a printed list in the other is a system design failure.

And the fourth, which is not optional: atomic holds at checkout

When two people click buy on the last ticket at the same instant, exactly one must succeed. This sounds obvious and is the single most common place a ticketing system is quietly broken, because it only fails under the load of an onsale, which is the one condition nobody tests. Inventory has to be reserved for the duration of checkout, with a countdown the buyer can see, and released automatically when they wander off. Ask how long the hold lasts and what releases it.

Per-person limits, counted properly

“Four per person” is trivial to enforce within one basket and nearly useless there. The limit that matters is counted across every order that person has made for that event, otherwise the buyer simply checks out four times. Ask which one it is. The honest answer from most platforms is the first.

Delivery, and what a ticket has to survive

A ticket has to survive a buyer who deleted the email, a buyer on a five-year-old Android with 2% battery, a buyer who bought six and forwarded three, and a show that moved to a different date.

• An email with a scannable code per ticket, inline in the message rather than behind a login. The buyer in the queue is not going to remember a password.
• A PDF attached, for the buyer who prints, and for the one whose mail client hides images.
• Wallet passes for Apple and Google, with an update service. The update is the point: when a show moves, the pass in their pocket should change, rather than a correction email they will not read.
• Passwordless order lookup by link. Accounts are a barrier that exists for the platform’s benefit, not the buyer’s.

The door

Covered at length in the guide for music venues, so briefly: the scanner should be a web page rather than an app, it should hold the manifest locally, it should decide while offline, and it should refuse duplicates while offline. It also needs a manual entry fallback for the ticket whose screen is too cracked to read, a guest list on the same screen, and feedback that works in a dark loud room, which means colour and sound and a buzz, not a subtle toast notification.

Will-call deserves its own mention. Somebody bought online and asked to collect at the door, which means a search by name, a pickup action, and an undo for when the wrong Sarah has been handed an envelope.

Refunds, exchanges and transfers

Three different operations, routinely conflated.

• A refund returns money and voids the ticket. It has to work on part of an order, because somebody bought four and two people can no longer come. And it has to void the wallet pass visibly, otherwise there is a scannable-looking object in somebody’s phone that will be presented at the door.
• An exchange moves a buyer between tiers, which means inventory has to move in both directions at once or the count drifts.
• A transfer gives a ticket to somebody else. The only correct implementation voids the original code and issues a new one. A transfer that just emails the same code to a second person has created a duplicate and moved the argument to your door.

Ask what happens to the platform’s own fee on a refund. If the ticket money goes back to the buyer but the platform keeps its cut, you are paying a fee for a sale that no longer exists.

Settlement, and a report that admits it cannot balance

After the show somebody has to work out what is owed to the artist, and that number has to be defensible to a tour manager in a corridor.

A settlement report has to be derived from the orders rather than typed, has to cover a single event or a date range, and has to include refunds, comps at zero, promo discounts and the actual processing cost including what the processor keeps on a refunded sale.

The property worth insisting on is subtler: a report that cannot balance should refuse to look authoritative. Financial reports fail quietly. A row goes missing, the total still renders in a confident font, and somebody pays a band off it. A report that says “I do not balance and here is the discrepancy” is worth more than one that is usually right.

Admissions tax and the date it hangs on

Many cities levy an admissions or amusement tax on ticket sales. Two things make it awkward, and most systems handle neither.

First, whether liability attaches on the date of sale or the date of the event varies by jurisdiction, and a ticket sold in November for a February show falls in different periods under the two rules. A system that can only report one basis will eventually make you reconstruct a year by hand.

Second, tax has to be a separate line in the total rather than folded into a fee, so that it can be reported and remitted. Ask to see a CSV export with the tax column in it before you believe the feature exists.

Staff, roles and the audit trail

A door volunteer should be able to scan and see nothing else. A box office person should see orders and issue refunds. Only an owner should change fees or bank details.

The question that separates real permissions from decorative ones: is the role enforced on the server, or only in what renders? Hiding a button is not access control. Ask whether a scanner-role account, knowing the URL, can open the refunds page.

Alongside that, sessions you can revoke per person for when a phone is lost, and an audit log on every refund, every comp issued and every email sent. Not for surveillance. For the night somebody asks why a ticket was refunded and nobody remembers.

General admission or reserved seating

Decide this first, because it eliminates most of the market in one move.

If you sell specific seats, you need a seat map: a drawing of the room, per-seat inventory, a picker that holds seats while somebody chooses, and rules for not stranding single empty seats. This is a genuinely hard piece of software, it is why seated platforms cost more, and there is no point evaluating a general admission product against it.

If you sell standing room with tiers, advance and door and a VIP level, a seat map is complexity you will pay for and never use.

Build, buy, or Gatehouse

Every venue that has looked at the fees has considered building it. Roughly, the honest version of that decision:

Building gets you a checkout in a fortnight and then two years of the list above. The checkout is the 10% everybody estimates; atomic inventory under onsale load, offline duplicate detection, wallet pass update services, settlement that balances and tax on two bases are the 90% nobody does. It is a reasonable decision only if software is already your business.

Buying is the default, and the question then is what the fee model costs you, which is a whole guide of its own, and what you give up in exchange: usually the buyer relationship, the payout timing, or both.

Gatehouse is the second of those, built so that the two things normally given up are not. The list above is not aspiration: holds with a visible countdown and database-level atomicity, comps at no fee, guest list beside the scanner, per-person limits counted across orders, wallet passes on both platforms with live updates, offline scanning with duplicates refused by a unique constraint, partial refunds, exchanges, transfers that void the original, settlement with a self-check, admissions tax on either basis, CSV export, four roles enforced on pages and APIs, and an audit log.

$1.00 a paid ticket, $49.99 a month or $449.99 a year, no percentage of face value, and no tier where the good scanner lives.