The seating chart changed, the BEO didn't — what to check before comp stations go out

A planner moves two tables an hour before doors. The banquet event order still reads the old layout. Someone has to decide, fast, whether that is a problem or just a Tuesday.

This is the exact seam to test when you evaluate a floorplan-forward tool against anything else on your shortlist. The question is not whether the tool lets you drag a table. Every tool does that. The question is what happens to the signed document, and to the kitchen's copy of the plan, the moment you do.

Below is a plain way to run that test on any demo, using what actually changes and what should not. You can compare Excellent vs Perfect Venue on exactly this point.

Does moving a table force a new signature?

It should not, and if a tool makes you re-sign for a seating change, that is worth noticing. In Excellent, a finalized BEO is locked by a snapshot — the rendered content plus a hash of it, stamped with who finalized it and when. Event seating is a separate thing: it is assigned against the event and the elements on its floorplan, not against the BEO. Changing the room after a BEO is final does not require re-finalizing the document. When you run this test on another tool, drag a table during the demo and watch whether it quietly invalidates a signed page or asks for a new round of sign-off. Either answer tells you something real about how the product is built.

If the BEO doesn't move, what record does the kitchen actually read from?

The kitchen reads a specific audience view generated at finalize time, not a live mirror of whatever the floorplan shows right now. In Excellent, a document is rendered into separate audience views — client, kitchen, FOH, internal — and finalizing freezes all of them into one snapshot. That snapshot is what the kitchen and floor views come from on the night. It is worth asking any vendor, plainly: when a table moves, does your kitchen view update automatically, stay frozen, or something in between? Each answer is a different design decision, and none of them is dishonest on its own — but you want to know which one you are buying.

Can a signed document be edited in place to reflect the new chart?

No — in Excellent, once a document carries a signature that has not been withdrawn, the system refuses to re-finalize it. Getting a changed version in front of people means publishing a new one, which is visible as a new document, rather than rewriting the page underneath a signature someone already gave. When you test a competing tool, look for the opposite failure mode: a product that lets someone edit a signed BEO quietly, with no trace that anything changed. A tool that refuses silent edits is protecting the one document everyone downstream is trusting.

Does the pre-shift briefing know about the new seating, or only the old BEO?

It knows what was on the finalized BEO, not what the floorplan says today. Excellent's pre-shift notes are drafted from the finalized BEO's floor-facing view — reading the immutable snapshot, never the live document — plus the day's 86 list and whatever the operator adds by hand. That means a seating move made after finalization will not retroactively rewrite the pre-shift note's picture of the room, because the note is built from the snapshot, not from the floorplan tool. The note is a briefing built on what the team was actually handed, not a live feed of every edit since. If you need the floor to know about a same-day seating change, that has to travel through a direct word at line-up, not an expectation that the document will catch up on its own. For a longer look at that handoff, see the walk from a signed BEO to tonight's pre-shift note.

What should an evaluation checklist actually test, live, in the demo?

Ask the vendor to do these three things in front of you, in this order:

• Finalize a BEO, then move a table on the floorplan. Confirm the signed document does not silently change and does not demand a new signature.
• Pull up the kitchen or FOH view after the move. Confirm whether it reflects the new seating or still shows what was finalized, and get a straight answer on which is intended.
• Generate tonight's pre-shift note after the move. Confirm what it says about the room, and ask where that information actually came from.

A tool that cannot explain its own answer to all three, consistently, is one you will be debugging during a live service, not during a demo.

How does this compare across the category?

This is the specific test worth running on any private dining software for groups you evaluate, not just one vendor. The deeper design question — whether a document is immutable once signed while the floorplan stays editable underneath it — is covered in full in why a signed BEO won't budge but the floorplan will. If you are coming from a spreadsheet or Planning Pod instead, the floorplan evaluation checklist covers the adjacent ground: to-scale editing, per-event seating, and capacity limits.

The short version

A seating change and a signed BEO are two different records, moving on two different clocks. Test, in the demo, whether a vendor's tool keeps them that way on purpose, or blurs them in a way nobody can explain when a table moves an hour before doors.