Brewery & Taproom Event Ticketing

The vertical decides the vocabulary, the questions asked at checkout, the inventory model, the door, the payout terms and the theme. This page says "spot" and "release" because that is what a taproom says; a config whose primary call to action is generic ticketing wording fails validation rather than shipping.

Who this is not for. Excludes beer festivals run by third-party promoters, which behave like seasonal-gate. If that is closer to your operation, the vertical you want is probably a different one — all twenty are listed here.

Everyone arrives at seven and the queue goes down the street

A release advertised as "doors at 7" is read as "be there at 6:45 or miss out", especially when the beer is limited. You have not sold ninety admissions across an evening — you have sold ninety simultaneous arrivals to a bar that can pour forty in the first half hour. The queue is the visible symptom; guests who leave, ID checks done badly under pressure and a first-hour service standard nobody would come back for are the expensive ones.

What bindro does: A release is timed-slot inventory here, not a single door count. Ninety spots become three thirty-guest pours an hour apart, each with its own spot count, and the guest picks a slot at checkout rather than being told a door time. Sizing the slot to your pour rate instead of your floor space is the whole trick, and the release guide works through the arithmetic.

The age check is a checkbox somebody ticked three weeks ago

Generic ticketing can ask whether everyone is 21. It cannot refuse the sale, it cannot tell the door what was asked, and the tick sits on the order rather than on the person drinking — who, on a party booking, is usually not the person who paid. That leaves the licensee holding an attestation with nothing behind it on the one night a licensing officer walks in.

What bindro does: Two separate controls, doing two different jobs. The booker attests that every guest is 21 or over, and separately gives their own date of birth — which is enforced on the money path, so an under-21 booker is refused rather than sold to and sorted out later. An unparseable date is refused too, because a rule that garbage bypasses is not a rule. Physical ID is then confirmed at the door and recorded against the scan rather than the order, and the compliance record is kept for 24 months because that is a licensing evidence horizon rather than a marketing one.

The arch has no signal and the scanner is a website

Converted railway arches, cellars and back yards are where taprooms are, and none of them has four bars of anything. A door tool that needs a connection turns the busiest twenty minutes of your week into a person with a clipboard reading names off a phone that is still loading.

What bindro does: The door device carries a signed manifest of who is admitted, scans against it working with no signal at all, and reconciles when it reconnects. Two things worth briefing staff on anyway: an offline room count is as fresh as its last sync, and a walk-in sold on a second device will not show on the first until both are back. Keep walk-in sales on one device and neither ever matters.

The walk-up till and the website disagree about how many spots are left

Two systems selling the same room is how a taproom ends up with ninety-one people holding a spot in a ninety-spot release. The argument happens at the door, in front of everyone, and it is always with the guest who is least at fault.

What bindro does: There is exactly one money path in bindro, so a spot sold at the door lands on the same order table, the same inventory pool and the same ledger as one sold three weeks earlier. Inventory only ever moves under a row lock inside the transaction that confirms the order, with a database constraint behind that as the backstop rather than the mechanism. The door cannot oversell the room while the website says sold out, because there is no second implementation for it to disagree with.

The glassware and the four-packs get offered at the busiest possible moment

The extra revenue at a release is not the ticket price — it is the branded glass, the takeaway four-pack of the beer being released, and the food. Offered across a three-deep bar by a server who is mid-pour, most of it simply does not get sold, and none of it gets counted against the release that generated it.

What bindro does: Add-ons are attached at checkout, before the guest arrives and while they are still excited about the beer, and counter sales on the night run through the same POS surface. Attach rate is one of the three numbers this vertical is scored on, so it is deliberately not buried three screens into a settings page.

You find out what the release actually made about three spreadsheets later

Ticket count tells you almost nothing. A sold-out Thursday at eighteen dollars and a half-full Saturday at forty look identical in a ticket count and are not remotely the same evening, and the comped spots you gave the visiting brewery quietly ruin your average spend either way.

What bindro does: Gross, platform fees and refunds are reported per release out of the ledger the payouts reconcile against; spots sold are shown against guests checked in with a no-show percentage; and orders and guests export as CSV whenever you want them. Comped spots consume inventory and scan like any other, but write no revenue lines at all, so the tap takeover where the guest brewer brings six people is not a hole in your numbers.

Timed pour slots, with a spot count on each

A release is modelled as timed-slot inventory: the release is the event, each pour window is a session, and each session carries its own spot count. Guests choose a window at checkout and remaining capacity is live per slot, so a slot that has gone says so instead of taking another booking.

• Size the slot to your pour rate, not your floor space — most small taprooms land between twenty and forty.
• Keep the last slot smaller: it absorbs the drift from every slot before it.
• Remaining spots per slot are visible while the release is running, on the day-of screen.
• A sold-out slot is sold out — waitlists are not declared for this vertical, and the page says so rather than collecting emails nobody will call back.

A 21+ gate that refuses the sale, not just the booking form

The age questions come with the vertical rather than being something you design: party size capped at ten, a 21+ confirmation for every guest, and the booker's date of birth with the bound enforced where the money moves. The door then confirms physical ID and that confirmation is recorded against the scan, because the booker is very often not the drinker.

• Under-21 date of birth: refused at checkout, not flagged for someone to notice later.
• The no-ID, no-refund consequence is stated on the booking page before payment, so the door only has to repeat it.
• ID verification is recorded per scan, with a time attached, not asserted once per order.
• Bindro does not scan or store identity documents and does not claim to have verified anyone — the responsibility sits with the licensee, and pretending otherwise would be worse than saying so.

A door that works in a cellar

Offline check-in is a requirement for brewery events rather than an add-on, so it is designed into the data model instead of retrofitted: the device holds a signed manifest, admits guests with no connection, and reconciles on reconnect. A guest who steps out to the beer garden and comes back scans in again at the door that admitted them, with no signal needed and no fresh credential; the same code at another door while they are already inside reads as already used, and names the door that used it. The visit is counted once however often it is scanned.

Door, merch and food on the same money path as the website

Walk-ups sold at the door, a branded glass attached at checkout, a four-pack or a food plate rung up at the counter — all of it goes through the one checkout engine that every other sale goes through, which is why the room count stays true and the release's numbers are complete.

• Walk-in spots sold on the operator device draw down the same inventory pool as online sales.
• Add-ons attach to the booking, so the glass is picked and paid for before the guest arrives.
• Counter takings are recorded so the release numbers are complete — but that money is already yours and never enters the platform ledger or a payout.
• Cash spot sales are deliberately not recorded: crediting the platform for money it never held would pay you for the same spot twice.

Gift cards that reconcile, and tax that stays out of your balance

A gift card is a liability account here, not a discount code: the money sits against gift-card liability until it is redeemed, and redemption is a tender line on the order with its own coherence check. Sales tax is calculated and held as a liability rather than mixed into the taproom's balance, so what is paid out is proceeds and what is owed is owed. Bindro does not file returns for you and is not a tax adviser — it gives you a defensible number and the report behind it.

Comps, refunds and a door login that sees almost nothing

The three controls a taproom reaches for in the week after a release, all of them yours rather than a support ticket.

• Comp a spot for staff, media or the visiting brewery: it consumes inventory and scans normally, and writes no revenue lines at all.
• Refund a guest yourself from the console — proceeds reverse first, then tax, then our fee, so the ledger is never left unbalanced.
• Promo codes for your mug club list, which is how a club price works here: member and non-member tiers exist, but checking a guest against a membership roster is not enabled for this vertical.
• A door-staff login sees a name and whether the code admits — not what anyone paid, not anyone's allergy answers, not anyone else's booking.

Who pays the booking fee?

The guest, unless you say otherwise. Every release carries its own setting — the guest pays, you absorb it, or you split it — and the fee itself does not change with the choice, only which side of the sale it comes from. On a ten-spot $25.00 release that is $16.20 either added to what guests pay or taken out of what you keep.

Because the default is the guest, a taproom can go from signing up to a sold-out release without paying bindro anything up front, at any point, ever. We are paid out of sales that happened or we are not paid.

The word "event" is load-bearing and worth reading twice. The scheduler groups by release, admits one only once its LAST session has ended, and pays it once. A release sold as a run of dates therefore pays after the final date, not after each one — a season's float is not something an operator should discover halfway through the season.

Bindro never pays before delivery, in any vertical. A pre-event advance is a configuration violation platform-wide rather than a policy someone can be talked out of, because paying out on releases that have not happened is exactly how a cancellation becomes guests with no refund. "Paid" also means the money moved: a payout only reaches its paid state with a real transfer reference attached, enforced by the database rather than by a status field someone can set.

• One payout per release, after its last session ends, one in flight at a time.
• T+2 for this vertical (low risk tier), no reserve.
• Refunds reverse in a fixed order — your proceeds first, then tax, then our fee — so a refund never leaves you charged for a sale that was undone.
• Sales tax, where it applies, is held as a liability rather than mixed into your balance, so the payout figure is proceeds rather than a number you still have to do subtraction on.

The three numbers underneath it are add-on attach rate, release sell-out speed and repeat guest rate. Attach rate is the one that moves fastest, because a glass or a four-pack attached at checkout converts far better than the same item offered across a three-deep bar. Sell-out speed tells you whether the release was priced right; repeat guest rate tells you whether the evening was any good.

The console computes revenue per taproom hour and prints the arithmetic under it — gross paid sales divided by the hours you actually delivered — beside the funnel stage by stage, where the traffic came from, and the attach rate with the two numbers it came from. Until a session has ended there is nothing to divide by, and it shows an em-dash rather than a zero.

What the console shows today, without an integration or a spreadsheet:

• Gross, platform fees and refunds per release, read from the ledger the payouts reconcile against.
• Spots sold against guests checked in, with a no-show percentage per session.
• Live remaining capacity while the release is running, per pool, on the day-of screen.
• This taproom's own funnel — view → slot selected → age confirmed → checkout → paid → attended — stage by stage with the drop-off between them, and any step the platform cannot see said so rather than shown as a zero.
• Refunds, transfers, turnout, no-shows, add-on attach and repeat buyers, each printed with the two numbers it was divided from.
• Orders and guests as CSV, so anything not on the screen is one export away.

Two more that are worth stating plainly. Sensitive answers are classified on the field rather than by convention, and health data is excluded from analytics exports and from AI context absolutely, with no override in any vertical. And a taproom's own people see only what their role allows — a door login sees a name and whether the code admits, not what anyone paid — which is checked in the handler rather than by hiding a button.

• Waitlists when kegs kick — a waiting list is not enabled for taprooms, so a sold-out slot is sold out.
• Verified member pricing — member and non-member price tiers exist as a pricing model, but checking a guest against a membership roster is not enabled here.
• Handing a spot to a friend — ticket transfer is optional for this vertical and is not turned on; a direct call is refused.
• Beer club subscriptions — recurring membership revenue is not attached to a release, and payouts settle per delivered event, so the engine could take the money and never pay it out. It is off on purpose.
• Season passes, donation add-ons and group registration — configured as optional for taprooms and not currently resolved.
• Replacing your bar POS — bindro sells and admits; it does not run tabs, tips or open-check service.
• Cash taken at the door — the walk-up till charges a card on the operator device. Cash spot sales are deliberately not recorded, because crediting the platform for money it never held would pay you for the same spot twice at payout.
• Bar and merch till takings as platform money — a till sale is recorded so the release numbers are complete, but the money is already yours and never enters the platform ledger or a payout.

If one of those is the thing you need, say so — the answer is a capability declared, built and gated properly, or a straight no. It is never a feature flag that collects the request and does nothing.

Announce first, sell second. A stated on-sale time concentrates demand into a moment you have staffed, which is far easier to handle than a trickle you have to keep watching; an on-sale three weeks out mostly buys anxiety, and two days out gives your regulars no chance to arrange a lift home.

On the night, the two door jobs stay separate. The scan answers "is this spot admitted"; the ID check answers "is this person 21", and only one of those has a licence attached to it. Walk-ups go through the door checkout on one device so the room count stays true, and a slot that has gone is refused rather than squeezed.

The morning after is three numbers and an export. Then the money: one payout for the release, two days after its last slot has ended, with no reserve held in this vertical — and never before, because paying out on a release that has not happened is how a cancellation becomes guests with no refund.

• Announce the release; set a stated on-sale time roughly ten days before the date.
• Three slots, sized to pour rate, with the last one smallest.
• Two people at the door, always: one scans, one checks ID.
• Read sell-out speed, attach rate and repeat guest rate; export the guest list.

A menu tool knows what is pouring and what it scores. It does not hold ninety spots across three timed windows, refuse an underage booking before it takes money, scan a code in a cellar with no signal, or release the takings two days after the release ends.

A taproom POS runs open tabs, split checks, tipping and keg-level depletion — an operational depth bindro has never claimed and is not building. Counter sales here exist so a guest at a ticketed release can buy a glass on the same money path as their spot, not so you can close your bar POS. If your ticketed releases do not need slot inventory and an enforced age gate, you may not need bindro at all, and the comparison pages say so in more detail.

The booking form already asks party size capped at ten, the 21+ confirmation, the booker's date of birth, dietary requirements with a free-text follow-up, and how the guest heard about you. Allergy answers are classified as health data on the field itself, which is what keeps them encrypted, out of analytics exports and out of AI context absolutely — not a setting anyone can forget to tick.

The page you are reading says "release", "spot" and "guest" because a taproom does. A vertical config whose primary call to action is generic ticketing wording fails validation rather than shipping, which is the shortest way to explain what this platform is actually for.