A party grows and a table moves after the BEO is final. What actually needs to change?

A host calls at four to say the party of ten is now fourteen. Or the client asks, an hour before doors, to move from the private room to the patio. Nothing about the event itself changed — the menu, the timing, the terms everyone signed off on are the same. What changed is the room.

The instinct on a busy day is to treat this like any other BEO problem: pull up the document, edit it, resend it, tell everyone to look at the new version. That instinct costs time you don't have, and it treats two different problems as one. Seating and headcount are floor logistics. The BEO is a record of what was agreed. They live in different places on purpose.

Here is what actually needs to happen, and why the document and the floor are not the same problem.

Does a seating change require re-finalizing the BEO?

No. Finalizing a BEO freezes the document as it stood at that moment — the rendered content plus a hash of it, stamped with who finalized it and when. Event seating is assigned separately, against the event and the elements on its floorplan, and it is not locked to a finalized document. Moving a table or growing a party does not touch the BEO's snapshot, so there is nothing on the document side to redo.

This matters doubly once a BEO is signed. A signed document cannot be quietly re-finalized — the system refuses a second finalize on it outright, so getting a changed version in front of people means publishing something new and visible, not editing underneath a signature someone already gave. If seating changes forced a re-finalize, a signed event would be stuck. It isn't, because seating was never inside that boundary.

If the document doesn't change, what does?

The floor's information does. The finalized BEO the kitchen and service teams were briefed from still says ten covers in the private room. Reality now says fourteen, partly on the patio. That gap is a briefing problem, not a paperwork problem, and pre-shift meetings are the standard mechanism restaurants use to relay day-of updates — including changes to reservations and private events — before service begins. Reviewing the floor plan during that meeting is recommended specifically so staff know where they're stationed and what they're responsible for, and some restaurants use the same meeting to reassign responsibilities on the spot when something like an event needs extra hands in a given area. A same-day table swap is precisely that kind of change.

This split — a finalized record on one side, a live day-of briefing on the other — is the same one covered in From a signed BEO to tonight's pre-shift note: two different objects, built for two different moments. The BEO is what was agreed. The pre-shift note is what the team actually walks in with.

Where does the pre-shift note get its facts, and does it catch a same-day change on its own?

Not by itself, no. A pre-shift note is drafted from the venue's live menu, the day's 86 list, whatever the manager adds by hand, and the finalized BEO for that venue on that service day, read from the immutable snapshot — so the note only ever says what the team was actually handed at finalize. That means the note reflects the party size and run of show as they stood then, not as they stand at four o'clock. Closing that gap is exactly what the manager adding it by hand is for. You can see how that draft comes together on the staff training page.

Why not just treat this the way some event tools do, and push a new document link?

Because the change here is not to the agreement, it is to the room, and pushing a document restates something that never moved. One competing model treats every change as something that should update a shared live link so nobody ever needs a document re-sent, which assumes the fix for a day-of change is always a refreshed document. A table swap or a headcount bump is not a change to the proposal or the contract at all; it is information the floor needs before the first cover arrives, and no version of the document, however current, delivers that on its own. Saying it out loud, once, to the people working tonight, does.

What actually needs to happen when the count or table changes same-day

A short list that holds up:

• Leave the BEO alone. Nothing about seating requires touching the finalized document.
• Tell the floor once, clearly, before doors — the new count and the new location together, not as two separate facts someone has to reconcile.
• Have the manager add the change to the pre-shift note by hand if it happened after the note was drafted, since the note only knows what the finalized BEO said at the time.
• Confirm with whoever runs seating that night that they're working from the actual table, not the one printed on the BEO.

The record stays exact. The team just needs the truth before service starts.