Who gets the signed PDF, and who only ever sees the pre-shift note?

A new manager's first hard question is usually not about food or service. It is about paper: who has the signed contract, who has the kitchen's version of the BEO, and who only hears about tonight's party at line-up.

This is a guide to that reach: which document exists, what it is built from, and where the trail stops on purpose. It also looks at what happens to that reach when the booking side of a business and the floor-briefing side run on two separate tools instead of one.

What makes the signed PDF different from every other version of the BEO?

The signed PDF is fixed at the moment someone signs it. Finalizing a document writes an immutable snapshot of exactly what was on the page, stamped with who finalized it and when, and the document then points at that snapshot rather than its live, editable version. A signature is recorded on the document artifact itself, and once a signature exists that has not been withdrawn, the document cannot be finalized again — a changed version has to be published as a new one, which is visible, rather than quietly replacing what was already signed. That is what makes it dependable months later: whoever opens it sees exactly what was agreed, not a guess about what the page used to say.

Who sees the kitchen and floor renders, and how do they differ from the signed PDF?

The kitchen and FOH renders are working documents built from the same source as the signed PDF, but narrowed to what each team needs to execute. The document engine produces several audience views of one BEO — client, kitchen, FOH, internal — and cost fields appear only on the kitchen and internal views, stripped out of the ones the floor or the guest see. This matches a pattern seen more broadly in the trade: most venues work from one master BEO but hand out simplified, department-specific slices of it rather than the whole document to everyone. For a closer look at what belongs in each section of that render, what a great BEO actually contains walks through it piece by piece.

Who only ever sees the pre-shift note?

Most of the floor — the servers and bartenders working a normal night — sees the pre-shift note and nothing upstream of it. The note is composed from the venue's live menu, the 86 list, and tonight's finalized BEO facts read from that BEO's own frozen snapshot, so what it says about an event is limited to what the team was actually handed, not a guess about the current plan. From the BEO's floor-facing view it pulls the event title, guest count, run of show, and allergens drawn from a closed list. A team running a private event still reads the BEO itself; the note is the briefing, not a replacement for it.

This lines up with how pre-shift meetings work elsewhere: short, run for the floor and kitchen team of that one shift, and sometimes kept as a standing internal record rather than something that travels up the management chain the way a BEO does. For a side-by-side reference you can hand a new hire, see the BEO cover page vs. the pre-shift note chart. The rule for when a note stops being enough and someone needs the actual BEO in hand is covered in when the note isn't enough.

Where does the document trail stop?

It stops at seating. Event seating is assigned against the event and the elements on its floorplan, and changing the room after a BEO is final does not require re-finalizing the document. The signed paper covers the agreement; the floorplan covers the room, and the two move on different schedules by design. Why a signed BEO won't budge but the floorplan will covers that boundary directly, with a concrete test to apply when evaluating a tool.

What changes about this trail when a sales tool and a floor tool are two separate systems?

The booking record and the floor's daily briefing have to be kept in sync by hand, because they live in different places. Event Temple, for instance, is built as hotel sales software — a sales-and-catering platform that carries a booking from inquiry through proposal, contract, BEO, invoice, and reporting. That describes a sales workflow, not a floor-briefing one. Without one connected record behind both the booking and the briefing, the kind of drift documented across the industry becomes possible: a guest count changes on a call, the invoice gets updated, and a kitchen's printed BEO still shows the old number, because nothing ties the two together as one source of truth.

Do you need one system for events and training, or is Tripleseat plus a separate LMS fine? works through the same seam from the training side.

Excellent keeps the signed PDF, the kitchen and FOH renders, and the pre-shift note built from one spine — the note is drafted by reading the same finalized BEO snapshot the signed document points at, not a separate copy stored elsewhere. If you are weighing this against private dining software for groups you already use, the side-by-side detail is on the Event Temple comparison page.

A short summary for a new manager's first week

• Signed PDF — fixed the moment it is signed; a new version requires a new signature, not an edit.
• Kitchen and FOH renders — built from the same BEO, cost stripped from the floor's view.
• Pre-shift note — rebuilt each day from whichever BEOs are finalized for that service day.
• Floorplan — moves on its own schedule, outside the signed document by design.

Knowing which document a person is holding tells you what they actually know about tonight, and what they don't.