Allergies and dietary requirements at a ticketed dinner: what bindro collects, and where the kitchen reads it

What does the booking form ask each guest?

Dietary requirements or allergies, per guest rather than per booking, from a list that includes vegetarian, vegan, gluten-free, dairy-free, nut allergy, shellfish allergy, halal, kosher and other. Choosing a nut allergy, a shellfish allergy or "other" opens a description box that must be filled in — "nut allergy" on its own tells a chef nothing about severity or cross-contact, and a blank box is refused on the money path rather than saved as an empty string.

Alongside it the form asks the booker for the number of guests, a mobile number for day-of changes, any access requirements, and whether the night is a birthday or an anniversary. The access question and the dietary question are both health-classed; the occasion and the party size are not.

• Dietary answers are per guest and travel with the seat, not with the payer.
• A nut or shellfish answer forces a written description before the order will confirm.
• Access requirements are asked once per booking and are health-classed too.
• Unknown answer keys are rejected, never quietly stored — an undeclared field is an unaudited channel.

Where can the kitchen read those answers today?

On the allergen sheet for that sitting, which is the page this guide exists to point at. It lists every seat on the service in booking order, with the requirements each guest stated and the written detail attached to the guest who gave it — AND a line for every guest who stated nothing, because an absent line reads as an unanswered question rather than as no requirements, and a kitchen plating twelve covers has to be able to count them. The same answers are in the guest CSV export.

It is gated harder than the rest of the console, because it is health data about named people: an owner or a manager only — not the door, and not whoever handles the money — a fresh phone verification even though you are already signed in, and every read recorded against your name. That is the trade for having it on a screen at all.

What has not changed is the advice underneath. Print it, take it to the pass, and still ask the question again at the table: a booking form is a record, not a substitute for the conversation that keeps somebody safe. Bindro is one channel now rather than none, which is not the same as being the only one.

Why is dietary information treated as health data at all?

Because it is, and because the platform decides that on the field rather than by anyone remembering. Every question declares a sensitivity class, and health carries hard consequences everywhere downstream: excluded from analytics exports absolutely, excluded from AI context absolutely, with no override in any vertical, and anonymised in place twelve months after the event by the retention sweep.

It also travels correctly when a seat changes hands. If a guest hands their seat to somebody else, the new holder answers the dietary questions themselves and the previous holder's answers are replaced rather than merged, so nobody inherits a stranger's allergy record.

What should never be promised to a guest?

That a dish is safe. No automated system — not the booking form, not the restaurant assistant, not a confirmation email — should ever tell a guest that their allergy is accommodated, and bindro is configured not to: allergy assurance and menu substitution are escalation topics that route to a human, and the assistant is instructed to route rather than answer.

The honest line to a guest is the one most restaurants already use: tell us at booking, tell us again when you arrive, and we will tell you what we can and cannot do with a set menu. A ticketed dinner has less room to improvise than a la carte service, which is exactly why the question is asked before the money is taken rather than after.