Catering execution checklist for private dining: sales-to-kitchen handoff and contingency run-book

Most blown private dining events don't fail in the kitchen. They fail in the handoff — the moment the signed contract leaves the salesperson's inbox and lands (or doesn't land) in the hands of the people who actually have to execute it.

The gap between what sales sold and what the kitchen can actually execute

You've probably lived some version of this: the event coordinator promises a plated four-course dinner for 80 in a room with induction burners and no hot-holding cabinet. Or the client confirmed "vegetarian option available" three weeks ago, and nobody documented that 22 of those 80 guests are actually vegan. The kitchen finds out at 4:15 PM the day of, when the count sheet finally gets walked back to the line.

This post is narrow on purpose. It's specifically about the sales-to-kitchen handoff for private dining and the contingency run-book that keeps a rough night from turning into a P&L problem. Banquet prep timing is already covered in the 72/48/24/4-hour prep templates and staffing calculator — this assumes that discipline is already in place. What this covers is what needs to be true and documented before that timeline even starts.

Where the handoff actually breaks

Sales and the kitchen speak different languages, and nobody translates. Sales thinks in "yeses." A good salesperson closes by removing friction — "Sure, we can do a passed-appetizer hour," "Of course we can accommodate dietary needs," "Absolutely, we'll do a dessert display." Each yes feels small in the moment. Stack them together on a single event and they become a menu the kitchen has never costed or tested, staged in a room that can't physically support it.

In practice, the break usually happens at one of three points:

1. 1
   The verbal add-on that never made the contract. Client calls two weeks out to add a raw bar. Coordinator says yes, makes a mental note, and it dies there.
2. 2
   The final count that arrives without a locked menu. The kitchen gets a headcount but not a confirmed course-by-course spec, so they're prepping to an assumption.
3. 3
   The equipment fantasy. Nobody physically walked the private room against the menu. The dish requires a sear-and-hold, and the room has one 20-amp circuit.

The handoff usually isn't missing — it's informal. It happens in hallway conversations and half-read email threads. The fix isn't more communication. It's a single artifact that both sides sign off on before anyone orders product.

The final menu spec pack

The spec pack is what ends the "I thought you said…" arguments. It's not a menu — a menu is what the client sees. A spec pack is what the kitchen builds against.

1. 1
   Locked course list — every item, exactly as it will be executed, with no "or similar" language.
2. 2
   Per-plate build sheet — components, portion weights, plating notes, and any pass-off sequence (cold garnish added at expo vs. on the line).
3. 3
   Dietary matrix — not a note that says "3 GF." An actual grid: guest count per restriction, which courses are affected, and the swap for each.
4. 4
   Yield and pull quantities — tied to confirmed count plus your overage rule. If costing discipline isn't solid here, the menu engineering system with yield-adjusted costing is the foundation this leans on.
5. 5
   Equipment call-out per course — what heats it, what holds it, what it's plated on.
6. 6
   Timing spine — fire times mapped to the service flow, including toasts, speeches, the 20-minute gap while the host does a presentation.

The dietary matrix is the single most skipped item. People write "vegetarian available" and think they're covered. Then a table of eight includes a shellfish allergy, a gluten intolerance, and two vegans, and the line is improvising three separate plates during the entrée rush.

The discipline that fixes this: no product gets ordered until the spec pack is signed by both the coordinator and the chef. That signature is the handoff. Everything before it is negotiation; everything after is execution.

The equipment and staging reality check

The room lies to you. It looks fine empty. Walk it with the actual menu and the problems surface quickly.

The staging diagram is deceptively simple: a hand-drawn or templated layout of the room showing service stations, hot-hold placement, the plating line, pickup path, and where servers stage before the door opens. It takes fifteen minutes to draw and prevents the single worst private-dining failure — a plating bottleneck that pushes course three 25 minutes late while the client watches their guests get restless.

“

Draw the staging diagram with the executive chef and the event lead on the first room walk to surface equipment gaps early.

A simple staging workflow diagram helps visualize where to place hot-holds, the plating line, and the pickup path — and clarifies whether you need a two-wave fire plan.

Worth naming directly: the longer the walk from kitchen to room, the more you need to bring the finish to the room, not the room to the kitchen. Events with a long transit path should pre-stage and finish on-site rather than plate-and-run.

The staging check also surfaces equipment gaps early enough to actually fix them — rented hot-holds ordered, circuit load balanced, induction burner fuel sourced — instead of discovering all of it the afternoon of the event.

Staffing the room, not the guest count

The common mistake is scaling straight off headcount — one server per X guests — without adjusting for service style. A family-style 60-top and a plated synchronized 60-top are completely different labor problems.

1. 1
   Plated, synchronized service (everyone eats course-by-course together): you need enough hands to fire an entire course in one wave, plus a dedicated expo who does nothing but sequence the room.
2. 2
   Family-style / shared plates

   fewer servers on the drop, but heavier on runners and clearing.

3. 3
   Stations / grazing

   light on the room floor, heavy on station attendants and replenishment.

The number that trips people up most often is the wave point. Every synchronized drop requires a burst of labor for a short window. Three synchronized courses means three bursts, and if you staffed for the average instead of the peak, every course lands late. Building a simple staffing calculator around guest count, service style, and number of synchronized wave points gives you a cleaner output: server count, runner count, expo need, and bar coverage.

Don't forget the roles that never show up on a guest ratio: the point person managing the client in the room, and the runner whose only job is the kitchen-to-room relay on long-transit events. Both tend to fall off the schedule until someone's scrambling.

The two-week contingency run-book

This is the part almost nobody builds, and it's the part that actually protects the P&L when something goes sideways. On private events, something usually does.

A contingency run-book is a set of pre-decided responses tied to the specific failure points of this event, written out in the two weeks before. Not generic — event-specific. The whole point is that when the problem hits at 6:40 PM, nobody is inventing a solution under pressure.

1. 1
   Count changes - Guest count rises more than 10% inside 72 hours → action: pre-approved supplement charge per head, capped menu items flagged, chef confirms product availability → owner: coordinator → P&L: protects food cost from an unpriced overage. - Count drops inside 48 hours → action: honor guarantee floor per contract, reduce prep only on items with same-day shelf life → owner: chef → P&L: recovers guaranteed revenue, limits waste.
2. 2
   Product failures - Key protein arrives out-of-spec or short → action: pre-identified substitute item + client notification script → owner: chef + coordinator → P&L: avoids emergency same-day sourcing at 2x cost.
3. 3
   Equipment failures - Rented hot-hold fails on-site → action

   two-wave fire plan activates, backup burner deploys → owner: expo → P&L: prevents comps for cold food.

4. 4
   Service failures - A course runs more than 15 minutes behind → action: pre-agreed pacing recovery (compress the gap between later courses, brief the client's point person) → owner: room lead → P&L: reduces comp/discount exposure.

The run-book should end where the finance work begins.

Tying the run-book to P&L close and reconciliation

Every trigger in the run-book has a dollar consequence, and if you don't capture it the night of, it disappears. Overage charges get forgotten. Emergency product buys get absorbed into the food cost blend. The event looks profitable on the contract and quietly bleeds on the actuals.

1. 1
   Note the trigger — count rose 14%, protein substituted, etc.
2. 2
   Log the financial action taken — supplement charged, product bought at emergency cost, comp issued.
3. 3
   Capture the dollar figure while it's fresh, on the event sheet, not from memory a week later.
4. 4
   Roll it into the event P&L close within 48 hours of the event.
5. 5
   Compare contracted margin vs. actual margin and flag the gap.

A realistic example: a plated dinner for 90 contracted at roughly $95/head. Two days out, the client adds 12 guests. Without a run-book, the kitchen scrambles, buys protein at a premium, and the added covers get served at the base price with no supplement — because nobody had a pre-approved add-on rate. Twelve covers of unpriced food cost plus emergency sourcing, and the event that should have cleared a healthy margin comes in noticeably thinner.

With the run-book, the count change triggers a supplement charge and a pre-vetted substitute, and the same event closes near its contracted margin.

Events that fire three or four contingencies and capture every one routinely close within a couple points of their contracted margin. Events that fire the same contingencies without capture come in short and nobody can say exactly why. That's the difference the reconciliation habit makes.

Where software quietly earns its keep

None of this requires software to work. A disciplined coordinator with a solid template and a signed spec pack gets you most of the way there.

But the failure points cluster around information that lives in too many heads and too many inboxes. That's where AI-powered operational software earns its keep. The practical wins are unglamorous: the spec pack lives in one place both sales and kitchen can see and sign off on, so there's no debate over which version is final. Count changes inside the cutoff window trigger the pre-set supplement rule instead of relying on someone remembering to charge it. Contingency events get logged against the specific booking, so when you close the event P&L you're pulling captured numbers — not reconstructing them from memory.

The value isn't automation for its own sake. It's that the handoff and the money trail stop depending on who happens to be paying attention that day.

When this level of rigor makes sense — and when it doesn't

A full spec pack, staging diagram, and two-week run-book is overkill for a 12-top set-menu dinner in your regular dining room. If the format is close to your everyday service and the count is small, a signed menu and a headcount are usually enough.

1. 1
   The event is off your normal service format — synchronized plated, stations, action stations.
2. 2
   The room isn't your standard dining space and hasn't been staged against this specific menu.
3. 3
   Count is large enough that a plating bottleneck ruins the night.
4. 4
   The client relationship or check size means a bad execution carries real financial cost.

High-volume operations running simple, repeatable private events with a proven format can reasonably skip most of this. Building a two-week run-book for the same 40-person buffet you've executed 200 times is process for the sake of process.

The dividing line is repeatability. The more novel the event — new format, new room, new menu, larger count — the more the handoff discipline and the run-book protect you. Private dining makes money on the events you execute cleanly and loses it on the ones you improvise through. The spec pack ends the improvising before the client ever walks in.

The spec pack ends the improvising before the client ever walks in.