What the AI actually puts in a pre-shift note, and when it refuses to guess

A pre-shift note is read fast, standing up, before the floor opens. If it says something wrong, nobody has time to check it against the BEO before doors. So the question that matters is not whether the note sounds complete — it is whether every line in it can be traced back to something real.

Excellent's AI draft for the pre-shift note is built around that question. It does not compose a note from scratch and hope the facts line up. It reads a fixed set of sources, and when one of those sources does not resolve cleanly, it leaves that section out rather than filling it in from a guess.

Here is what it actually reads, what it refuses to touch, and where a person still has to look at the page before line-up.

What does the AI draft pull from?

It pulls from four sources: the venue's live menu, the current 86 list, whatever an operator adds by hand, and the finalized BEOs on the books for that venue and service day. Those BEO facts come from the immutable snapshot taken when the document was finalized, not from a document someone might still be editing, so the note can only ever say what the team was actually handed. From the BEO, the draft reads the front-of-house audience view specifically, the one already stripped of cost figures, and pulls the event title, guest count, run of show, and the allergens present on that menu.

This mirrors the ordinary shape of a pre-shift meeting at any restaurant: covering menu changes, 86'd items, and anything major happening that shift is standard practice, and reviewing the current 86 list before service is how servers avoid selling something that is not there.

Why does it read the FOH view instead of the full BEO?

Because that is the audience the floor is briefed for. The document engine generates multiple views of the same BEO — one for the kitchen, one for the front of house, one internal, one for the client — and each strips information the reader does not need. Cost fields, for instance, never reach the FOH or client views. The pre-shift note draft reads the FOH view because that is what the floor is supposed to see: the run of show, the guest count, the allergens, not the internal pricing or kitchen prep notes that belong to a different reader entirely. This division of views by role is common practice in banquet planning more broadly — kitchens and front-of-house staff are typically handed different slices of the same underlying event order.

A private or complex event still gets read off the BEO itself. The note is a summary for a normal shift's worth of tables, not a substitute for the document a captain studies before a large private dinner.

What happens when a BEO doesn't resolve cleanly?

It gets dropped from the draft instead of guessed at. If a BEO's event or its finalized snapshot does not resolve to a real record — a broken reference, something half-finished, anything that does not check out — that BEO is left out of the note rather than summarized from whatever partial information exists. A service day with no finalized BEO at all produces exactly the note it always produced: menu, 86 list, and whatever the operator wrote by hand.

This closed-set refusal behavior is not an accident of the design. Systems handling records this sensitive are generally built to answer only from what they are given and to have explicit conditions under which they decline rather than infer. A tool that never says it does not know something, in a workflow with allergen lines and guest counts riding on it, is a reason to look closer, not a reason for confidence.

Does the note replace the BEO on the floor?

No. It is a summary of tonight's finalized BEOs, and it is meant to be read alongside the document itself, not instead of it — a point covered in more depth in the pre-shift note vs. the BEO. A server working a straightforward table can probably work off the note. A team running a private event, with its own run of show and its own allergen detail, still needs the BEO in hand. Dietary restrictions and allergies belong in their own clearly flagged section of a BEO precisely because burying that detail carries real safety risk — which is part of why the note pulls allergens from a closed list rather than free text.

Where does a person still have to step in?

At the point where the AI's draft stays a draft, not a publish. The note moves through a draft-to-published status, which means someone reads it before it reaches the floor. That review is also the moment to catch what a fixed source list cannot: an operator detail meant to be added by hand and left out, or a BEO that was dropped from the draft because it did not resolve. For the broader case of what a trainer hands a new hire to compare the two documents side by side, see the BEO cover page versus the pre-shift note.

For a wider look at how a team reviews and trains on documents like this before they reach line-up, the staff training tools in Craft are built around the same idea: a fixed set of facts, reviewed by a person, before it reaches the team standing at line-up.

The short version

The AI draft reads the live menu, the 86 list, operator notes, and the FOH view of any finalized BEO for that service day and venue. It pulls guest count, run of show, event title, and allergens from a closed list, not free text. When a BEO does not resolve — a broken reference, an unfinished record — it is left out of the note rather than summarized from a guess. The note still moves through review before it is published, and it is meant to sit next to the BEO on a complex event, not stand in for it.