The taproom door runbook: scanning, refusals and the night the wi-fi dies

What should each door role be able to see?

The least that does the job. A door-staff login in bindro sees a guest's name and whether the code admits — not what was paid, not what was declared, not anyone else's booking. Roles are checked in the handler, not by hiding a button, so a volunteer who finds a URL still gets nothing.

That matters more at a taproom than it sounds. Allergy answers on a brewery booking are health-class data; they belong with whoever is pouring or plating, not on a scanner held by someone on their second shift.

• Door staff — scan, admit, refuse. Names only.
• Manager — the room count, refusals and the ability to sell a walk-in.
• Volunteer — the narrowest role; use it for anyone helping for one night.
• Finance and owner — money. Nobody at the door needs it.

What happens when the network drops mid-release?

Nothing visible, which is the entire point. Offline check-in is a requirement for brewery events rather than a feature: the device carries a signed manifest of the codes that admit, scans against it with no connection, and reconciles when it gets one back. A converted arch with no bars of signal is the normal case, not the exception.

Two things to brief staff on anyway: the room count on an offline device is as fresh as its last sync, and a walk-in sold on a second device will not appear on the first until both reconnect. Keep walk-in sales on one device and you never have to think about it.

How do you handle a refusal without ruining the evening?

Move it away from the door and make it short. The two refusals a taproom actually sees are no ID and visibly intoxicated, and neither is a negotiation. Bindro puts the no-ID consequence — refused entry, no refund — on the booking page before payment, so the guest has already agreed to it, and door staff can say so without inventing a policy on the spot.

Intoxication and refusal of service is one of the topics the taproom assistant is configured to escalate rather than answer, for the same reason: it is a licensee judgement, and no automated system should be making it.

Can a guest come back in later?

Yes. Re-entry is enabled for brewery events, so the same code admits again — a guest stepping out to the beer garden, to a smoking area or to move a car is the expected behaviour rather than an exception someone has to override. Check-in is single-point for this vertical, so there is one door to run and one count to trust.

What do you do the morning after?

Read three numbers and export the guest list. Sell-out speed tells you whether the release was priced right, add-on attach tells you whether the glass was offered at the right moment, and repeat guest rate tells you whether the evening was any good. All three are the KPIs this vertical is built around, because raw ticket count cannot distinguish a good Thursday from a bad Saturday.

Exports carry the guest list, and your own guest CSV carries a column per question you asked, dietary and allergy answers included, behind a fresh verification step. The analytics exports are the ones that drop them: health-class data is excluded from those and from AI context absolutely, with no override in any vertical.