Restaurant Course Controls: When Should a Dish Reach the Kitchen?

A restaurant order can contain every dish the guests requested without telling the kitchen to prepare everything immediately. If your service depends on courses, specify which action releases each course and how staff recognize what is still waiting. A course label alone is not a preparation instruction.

This is a commissioning guide for order pacing, not guidance on safe cooking, allergy handling or food storage. Those procedures require their own competent operational review.

Define what saving the order starts

The Odoo 19 restaurant documentation provides a concrete example: courses split an order into stages sent to the kitchen sequentially. Its documented Order action sends the order and also fires the first course. Later courses are fired separately after reopening the order.

That first-course side effect matters. Ask whether saving a draft, confirming a guest's choices and releasing preparation are separate actions in your proposed system. Do not design a button called simply Save if staff reasonably expect it to retain an unfinished order but it starts kitchen work.

In a fictional bistro, starters should begin while desserts remain held. Agree how that distinction appears to the server and kitchen. The entire order may be visible for planning without every line being ready for preparation; visibility and release need separate meanings.

Choose who may fire the next course

Decide whether any server assigned to the table can release the next stage or whether a named role controls pacing. Show which course is next, what it contains and whether its release has already been recorded.

A useful specification distinguishes held, release recorded, preparation acknowledged and ready for collection if those observations exist in your workflow. Do not display acknowledgement or readiness merely because someone pressed Fire. The cited course instructions do not establish that kitchen staff received, read or completed the work.

If the kitchen uses paper, decide how staff report a missing ticket. A successful application action should not be presented as proof that paper physically emerged from the correct printer.

Explain changes after preparation starts

Odoo documents moving a product or an entire course into another course. That supports reassignment as a product example, not a promise that moving an already fired dish withdraws a kitchen instruction.

For your project, separate edits before release from changes after release. If a guest moves a dish from the second course to the first, does it need a new preparation instruction? If preparation has begun, who contacts the kitchen and records the agreed outcome? Do not silently erase the old instruction and assume physical work reversed.

Keep the changed item, previous course and required follow-up understandable. These are proposed controls, not verified Odoo revision-history features.

A reprint is not a fresh cooking request

The same documentation describes reprinting a duplicate of the last kitchen order. Agree how your team distinguishes a replacement ticket from newly requested preparation. Otherwise a missing-paper investigation can become a second meal.

When a connection fails during release, require staff to inspect the recorded course state and reconcile with the kitchen before repeating an uncertain action. Software cannot infer from a timeout alone whether preparation started.

Demonstrate the dinner, not only the buttons

Use synthetic orders in your acceptance criteria. Enter several courses, release the first and demonstrate that later dishes remain held. Release the next course, try a repeated action, move an unreleased dish and request a change to a dish already in preparation. Finally, demonstrate a duplicate ticket and an uncertain release outcome.

Bring the actual service sequence to a restaurant workflow integration discussion. The useful result is a shared understanding of what the kitchen should do next, not merely numbered groups on a till screen.