A VIP or allergy is added after the BEO is final. What changes on the floor?

A host calls two days before a private dinner and mentions a guest with a shellfish allergy. Or the client adds a name to the list and flags them VIP. The BEO is already final. Nobody wants to reopen a signed document over one guest's meal.

You do not have to. Named guests — with meal, VIP flag, and allergen tags — are stored separately from the BEO document, and adding one does not touch the finalized snapshot. But storing the detail and getting it in front of the person plating the shellfish-free entrée are two different problems. This post walks through both.

Does adding a guest detail require re-finalizing the BEO?

No. A finalized BEO is an immutable snapshot of what was on the page at the moment it was finalized, and event seating is assigned against the event and its floorplan, not locked to that snapshot — changing the room after a BEO is final does not require re-finalizing the document. Adding a guest, flagging them VIP, or tagging an allergy afterward works the same way: it changes the guest list, not the document. The BEO stays exactly as signed.

That separation is useful on its own terms. A signed document cannot be quietly re-finalized underneath the people who already signed it, so a late-arriving detail should not have to force anyone back into that document at all.

Where does the new detail actually land?

On the seating chart, first. Event guests carry a meal, a VIP star, and a per-table seat, and the shared seating chart derives a per-meal plate tally from that list — the same chart used for the BEO and the prep sheet. So the moment someone is tagged gluten-free or starred VIP, the room's meal count and its named-guest detail update in one place. That chart, not the finalized BEO text, is the operational record of who is eating what and sitting where right now.

Second, and separately: the floor. A finalized BEO reaches the team through the pre-shift note, which is drafted against that document's own finalized snapshot — guest count, run of show, the allergens present in the menu itself, read from what the team was actually handed. A note built before the guest was added will not know about them, because the note reads a fixed snapshot rather than a live feed of every change since.

Does the pre-shift note update itself?

Not on its own. The note is composed once for the service day from the venue's live menu, the day's 86 list, anything the operator adds by hand, and the finalized BEO for that venue and day — it does not re-draft itself every time something changes afterward. If the allergy or VIP flag arrives after that note was drafted, it needs a fresh note, or a direct word to whoever is running the floor tonight.

This is the same pattern as a same-day table move: the underlying record can shift without touching the BEO, but the floor only knows what it is told. Our post on same-day BEO changes and table swaps covers the seating side of this in more depth; the mechanism for a guest detail is the same — the record updates quietly, the brief has to update on purpose. See how pre-shift notes work if you want the fuller picture of how that daily note gets built from a finalized BEO.

Who is responsible for getting the word out?

Whoever adds the detail is the one who knows it exists, so a direct handoff to the shift lead is the safer default when time is short. Pre-shift meetings are where higher-end venues typically share exactly this kind of thing — VIP guests, special requests, booking notes — and guest tags like VIP status are a normal part of that briefing. If the allergy lands after the day's note was drafted, waiting for tomorrow's note means tonight's floor never hears it. A short verbal or written re-brief closes that gap in the meantime.

Industry guidance on banquet documentation makes a related point: VIP needs and allergies should be flagged prominently rather than buried in a general note, since burying them risks serious consequences. The mechanism matters as much as the flag — a tag sitting only in a guest record that nobody re-briefs from is not meaningfully different from no tag at all.

Does the kitchen need anything different from the floor?

Yes: the same fact, delivered differently. Good BEO practice ties a dietary restriction to a specific guest count rather than one blanket note, because the kitchen needs to know if it is preparing three gluten-free plates or twelve — not just that gluten-free exists somewhere in the room. The seating chart's per-meal tally is built to answer that version of the question, since it counts meals by type across the room. The floor's version of the same fact — matching a plate to a face — still depends on a server having heard it before service starts, which is what the pre-shift note or a direct re-brief is for.

A plain habit some floors use for this: a discreet mark tied to a seat number, checked during a walk of the room before doors open, so a server does not have to hold the whole guest list in memory at the pass.

What if the new detail seems to conflict with what is already on the BEO?

The BEO's menu and its own allergen list were accurate at the moment it was finalized; a new guest detail is additional information layered on afterward, not a correction to that document. If a dish on the BEO looks wrong for a newly flagged allergy at one seat, that is a floor and kitchen conversation to resolve before service, not a reason to touch the finalized document — the amendment path for a signed document exists for real menu or run-of-show changes, not for one guest's meal note.

In short

A guest added after the BEO is final does not require reopening anything: the guest list and the seating chart hold that detail, and the BEO stays exactly as signed. What it does require is making sure the detail actually reaches the floor and the kitchen — through a fresh pre-shift note or a direct re-brief — because neither updates itself once the day's briefing has already gone out.