Field notes

Your BEO changed. Did the pre-shift note notice?

A walk through one day where a banquet order changes and the training and briefing side never hears about it, and what sharing one record actually requires.

Picture a normal Tuesday. Sales finalizes a BEO for Saturday's forty-top buyout at ten in the morning. By two, the client calls: two more chairs at table six, and a late-arriving guest has a shellfish allergy. Someone updates the seating chart. Someone, maybe, tells the kitchen. Nobody touches the pre-shift note, because the pre-shift note lives in a different piece of software, built by a different vendor, with no idea the BEO exists.

This is the ordinary condition of running events in one tool and training or briefing in another. Each system may be doing its own job correctly. The gap sits between them, and it is where allergen tallies go stale, VIP flags go unseen, and a run-of-show that changed at 2 p.m. is still the one printed at line-up.

The question worth asking is not whether a export button exists. It's whether the two surfaces read from the same underlying record of the event, or whether someone has to carry the facts across by hand, correctly, every time.

What specifically breaks when training and events live apart?

Three things break in a predictable order: the allergen tally, the VIP flag, and the run-of-show.

An allergen tally is only accurate if it comes from the same finalized document the kitchen is cooking from. If the pre-shift briefing comes from a standalone training tool with no view into the BEO, someone has to retype the allergen list by hand, and a later change to the BEO has no path back to that briefing at all. The same goes for a VIP note on the guest list and for a run-of-show listing the order of toasts, courses, and speeches: if the briefing tool and the event tool don't share a record, each one holds a copy, and copies drift the moment the original changes.

This is not a theoretical risk. Outdated BEO versions circulating, and allergen information that never reaches the people serving the table, are counted among the common operational misses in banquet service generally — a plain fact about the trade, not a claim about any one piece of software.

Why does a changed BEO never reach a separate training tool?

Because a standalone learning platform was built to hold courses and completions, not banquet orders, and it has no reason to watch for a BEO update at all.

A generic LMS is good at tracking who passed what quiz. It carries no notion of a finalized BEO, a seating chart, or an 86 list, so it cannot pick up a change in those records even if it wanted to. Training completion data can sit in one database while the floor manager's view of who is cleared for a station sits in another, with neither able to see the other, let alone a tonight's-party level of detail. A nightly export or a webhook narrows that gap; it does not close it, because it still hands over a snapshot from some earlier moment rather than the current state of the room.

What does sharing one spine actually require?

It requires the pre-shift note to be drafted by reading the same finalized BEO the kitchen and floor are working from, not a copy of it.

In Excellent, the pre-shift note is composed from the venue's live menu, the 86 list for that service day, anything the operator adds by hand, and the finalized BEO or BEOs on the venue's calendar for that day. Those BEO facts are pulled from the document's immutable snapshot — the exact record created the moment the BEO was finalized — not from some separately maintained copy, so the note can only ever say what the team was actually handed. The note folds in the floor's own view of the document (cost already stripped out), plus that view's event title, guest count, run of show, and the allergens present in that menu, drawn from a closed list rather than free text written by hand. If a BEO or its snapshot doesn't resolve cleanly to a real record, it is left out of the draft rather than guessed at.

That is the architectural difference between "integrated" and "synced." A synced system copies data across a boundary on some schedule. A shared spine means the briefing tool and the event tool are reading the same record at the moment someone opens it. One finalized document, one place it lives, and every surface that needs it reads from that place instead of a stale export. You can read more about how the event side and the training side fit together on the private dining and events page.

What a pre-shift note still leaves out

A pre-shift note is a summary, not a replacement for the BEO itself. A team working a complex or private event still reads the finalized document directly for the detail the summary was never meant to carry — a point covered in more depth in the pre-shift note vs. the BEO.

In short

The failure described here is not a missing feature so much as a missing connection: two tools, two databases, and no shared record of what a Saturday buyout actually looks like today. Closing that gap means the floor's daily briefing is drafted from the same finalized document the kitchen already has, read fresh each time rather than copied once and left to go stale.