Hotel Banquet Kitchen Planning: Design for Peak Service

From event brief to kitchen run-of-show

Start from the current signed-off event brief or banquet event order. For each event, the kitchen run-of-show should record the event ID, date, guest count, menu, portions by course, and how dietary requirements are routed through the proper restricted records. For each course it records the handover time, location and owner. It also records the document version and who owns changes.

Count carefully. Several courses may serve the same guests, so total plates are not unique guests, and adding up covers across the day does not give you the peak. The peak is the plates that must leave in the same window from the same resources.

Banquet event orders are commonly used to set out each event's specifications, including date, guest count, menu and run of show, and to give every department a shared document to review and update as details change. The kitchen run-of-show takes that information and adds the production and handover detail the kitchen needs.

Measure capacity with menu trials

Plate rates on paper are guesses. Run menu trials with the real team, the real equipment and the actual dishes, under the constraints of the site, to establish a useful capacity for each line. Record the conditions of the trial so later comparisons are fair.

Keep clean food and dirty returns separate as a layout principle, and have the layout reviewed by qualified people. Nothing in this guide sets holding times or temperatures.

The FSSAI voluntary catering guidance describes forward flow, separation of activities and access for cleaning as general layout considerations. It is guidance only, and current regulations take precedence.

Worked example: two events, one line

In this fictional scenario, a shared plating line has been observed to complete 8 plates a minute under the stated conditions. The approved working window is 18:45 to 19:00, which is 15 minutes. Event A needs 120 completed plates at the pass at 19:00 and Event B needs 80 at the same pass handover time, both from the same line.

Demand is 200 plates. The required rate is 200 divided by 15, about 13.33 plates a minute. The line's nominal capacity in the window is 8 times 15, which is 120 plates. That leaves a shortfall of 80. Every figure here, including the rate and the window, is invented. None is a benchmark or an approval to hold food.

A separate scenario: an approved stagger

Consider a different scenario. Suppose Event B's client and the operations team approve a pass handover at 19:10, with a workable plating window from 19:00 to 19:10. Event A uses the line from 18:45 to 19:00, plating 120. Event B then uses it from 19:00 to 19:10, and 8 times 10 gives 80. The nominal arithmetic fits those two pass deadlines, with no unused capacity in either window. Actual service still needs verification.

This is a scenario to raise, not a decision the kitchen can take alone. It does not change any guest's arrangements or timings without approval, and it does not approve holding food.

A second line that is genuinely independent and fully supported at 8 plates a minute would give 240 plates in the original 15 minutes. But shared staff, the pass, lifts or diet checks can remove that gain. Verify the full route before treating a second line as the answer, rather than assuming new equipment will fix it.

Plates must reach the table

A plate leaving the pass is not a plate served. Plan the route to each room, including lift and corridor capacity, and allocate a dispatch buffer explicitly. Do not count the same minutes twice, once for plating and again for dispatch. Two windows on the same resource cannot overlap unless capacity has been allocated between them. The example deadlines are pass handovers; guest service times require the separately validated route and dispatch allowance. If a deadline is instead at the table, move the pass deadline earlier before calculating the available plating minutes.

Main courses and desserts may use different equipment, plates and windows, so model each course separately. The return loop matters too. Clearing one event can peak while the next is being served. A wash cycle time alone leaves out loading, unloading, drying and storage, so plan the whole return flow.

Treat a model that fits exactly as a reason to investigate resilience. A delayed tray, missing garnish, change of plate or interruption could consume the whole allowance. Record the fallback and the person who can approve it. A capacity surplus on one stage does not offset a shortage at a later shared stage unless the route actually permits it.

Control changes to the brief

Keep one current version of each event brief so that no team works from a different count. Lock confirmations at the time the operation has agreed for that kind of event; there is no universal deadline.

A late change needs an impact review against the run-of-show and a named approval. Do not silently accept a count the kitchen cannot deliver. Record the change, the review and the decision in the change register.