The private-event day-of playbook: what changes between doors-open and dessert

A private event runs on a document that was final days ago and a floor that keeps learning new things right up until dessert. Both are true at once, and the operator's real job on the night is knowing which changes belong in writing and which ones do not.

This is not about whether the BEO is good. It is about what happens to it, and around it, once doors open. A lot of the friction on event night comes from someone reaching for the wrong channel — trying to amend a signed document mid-service, or assuming a briefing note will catch something it was never built to catch.

Here is the timeline, broken into the moments that actually change something, and what each one touches.

What happens to the BEO once it's finalized?

Nothing changes on the document itself. Finalizing writes an immutable snapshot of the rendered content, and the document is marked final and points at that snapshot; later edits create new versions rather than reaching back to alter it. That is the whole point of finalizing: the team that studied the document three days out is looking at the same thing the kitchen prints tonight. For the mechanics of how that snapshot becomes tonight's paperwork, what a great BEO actually contains covers the document itself; this post covers what happens around it once service starts.

One finding on BEOs generally is worth naming here: some venues attach binding signature language to the final version, specifically around headcount or menu, which is part of why reopening that document once it is signed is treated carefully — the stakes are not only paperwork.

A guest count drops right before doors. Does the BEO change?

No. Once a document carries a signature, the system refuses to re-finalize it, so a last-minute count change does not touch the signed BEO. A VIP cancellation, a last two guests who do not show, a plus-one who does — none of these reopen the document. What changes instead is the note the floor is actually briefed from that day, a separate surface drafted against the finalized BEO rather than a rewrite of it. This is exactly the situation covered end to end in a VIP cancels and the guest count changes after the BEO is final — worth reading if this is the scenario you hit most often.

A table moves or a table gets added mid-event. Does the BEO need to change?

No re-finalizing is required. Seating is assigned against the event and the elements on its floorplan through its own dedicated function, separate from the document engine, so a room change on the night is not a paperwork event. The full mechanics of this are in the floor plan changes after the BEO is final.

What carries a new allergy that shows up after the BEO is printed?

The finalized BEO is not touched, but the floor still has to hear about it. A pre-shift note is built from the venue's current menu, the day's 86 list, whatever the operator adds by hand, and the finalized BEO for that service day — so it can reflect a known allergy already on that menu, drawn from a closed list of allergen terms rather than free text. A VIP or allergy is added after the BEO is final walks through that gap in full.

One piece of general trade practice is worth naming here, separate from any one tool: the usual route for an allergy that comes up during service is that the server flags it on the ticket, tells the kitchen directly, confirms again before the dish leaves, and pulls in a manager if there is any doubt at all. That habit exists because a plate is about to go out, and the distance between a fact someone just learned and a dish someone is about to send has to close fast, in person.

Who is watching for a change nobody flagged?

Someone has to be, because a pre-shift note is meant to cover only what will affect the next few hours of service, not act as a running record of the whole night, so anything that happens after the huddle needs its own way of reaching the floor. On a private event with a tight run of show, that job usually falls to whoever is standing in the room: the floor manager or captain who saw the BEO, heard the pre-shift note, and is present when something shifts at 7:40 that nobody wrote down. Part of that job, in the general trade sense, is checking that a piece of news — a table moved, an item 86'd — actually reached every server it needed to, rather than assuming it did once it was said once.

A short list that holds up

• If it was true when the BEO was signed and it is still true, the floor reads it off the document or the note — nothing to route.
• If it changed after signing and it is a seating or headcount shift, it can show up in the pre-shift note; it does not require touching the BEO.
• If it is a new detail discovered the day of, after the note is already out, it needs a direct handoff in the moment rather than waiting on a document.
• If it is a small floor decision, it stays verbal, in the moment, and does not belong in either document.

None of this depends on memory holding up under service pressure. It depends on knowing, before the first guest walks in, which of these buckets tonight's surprise belongs to. See how pre-shift notes are built for a look at how the finalized BEO and the day's 86 list roll into the note the floor reads before service — but sorting a change correctly matters whether or not a tool does it for you.

If you want the fuller picture of how a signed BEO becomes tonight's briefing in the first place, from a signed BEO to tonight's pre-shift note is the companion piece to this one.