Ordered does not yet mean released
A guest chooses starter, main and dessert at the beginning of the evening. The kitchen needs to know the choice, but should not finish the main immediately. The distinction between an entered order and a release to production is at the heart of useful course handling. Bonzumo supports releasing menu courses individually. Decide who watches the tables pace, who triggers the course and which station receives the work instruction. A printed ticket without clear timing does not explain the sequence.
The most useful rehearsal uses a real table situation. Three guests eat at different speeds, one has skipped the starter and two mains need different lead times. Service should be able to pass the information so kitchen starts neither too early nor only after a complaint. Define what “order entered”, “course released”, “in progress” and “ready” mean in your restaurant. Both teams should understand these terms in the same way.
Separate advance information from a work order
Some kitchens want to see every course early to plan preparation. Others want a production job only when a course is released. Either can work if the display is unambiguous. An advance ticket must not look like an instruction to start cooking now. In the demo, inspect what appears on the KDS and paper and what action each entry triggers. An unclear duplicate view can waste more time than early information saves.
Consider a table with four set menus and a shared bottle of wine. Kitchen may need to know the planned courses, while bar should work on the wine immediately. If the main begins only after a signal, that signal must reach the correct kitchen station. Decide whether paper at entry, at release or at both moments is really useful. The answer comes from the work areas, not a generic printer setting.
Give service ownership of pacing
Service can see whether a table is ready for its next course. Kitchen can see its queue and preparation times. Both views matter. If nobody owns the release, a course may appear in the order yet never start. If several people release it independently, duplicate jobs become possible. Decide who triggers the next course for each table or shift and how a colleague taking over can recognise the current state. Shared order context works only when ownership and status are clear too.
The right moment is not always a fixed number of minutes. Guests may want a pause, wait for someone or choose a dish with a longer preparation time. Use Bonzumo for a traceable release and discuss exceptions openly between service and kitchen. Software can carry a clear signal; it cannot decide whether guests have finished talking or the table is cleared. Hospitality remains the measure of good pacing.
Check destinations for each course
A set menu may contain a cold starter, a hot main and a dessert prepared in different kitchen areas. If all courses go to one printer, a station has to sort tasks for the others. If a course is sent too early to several places, the relationship may be lost later. Map which station handles each item in a sample menu and where shared steps meet at the pass. Output should show the work that already exists, not create a new sorting job.
Sides, course drinks and substitutions deserve particular attention. A different dessert may need a different station; a side may make sense only alongside the main. Build a three-course test order with at least one such exception. Check that each station sees its relevant job and that the table reference remains when items meet at the pass. This turns printer and KDS choices into a process question for kitchen and service together.
Make KDS status and paper refer to the same job
A screen shows work that is open or being handled. Paper may still be useful at a station or the pass. What matters is that both outputs refer to the same job. A reprinted ticket must not look like a new table; a screen item marked complete should not continue in a paper pile without explanation. Decide which status the team treats as authoritative and what someone does when views disagree. The work remains understandable even when not everyone sees the same screen.
Try a course with two items that finish at different times. Who marks each step, and when may service collect the complete course? One ready signal for a whole table may be too broad; many tiny statuses can also burden a busy kitchen. Use a trial to find useful detail. Bonzumo supports kitchen status; its practical value depends on how well it matches the real handovers.
Handle changes after release differently
A change before release differs from one made after the kitchen has begun. A guest may swap a side, ask to delay a dish or cancel an item. First check which course has already been released and who saw the original job. The change should be visibly connected to it. An extra ticket without context can produce two plates instead of one corrected order.
Agree a short conversation for such cases. Service records the change, informs the responsible station and receives confirmation before promising a guest something that is no longer possible. Cancelling a dish already in preparation requires a decision on site; no interface can undo food already made. A rehearsed handover reduces arguments about responsibility and supports an honest answer to guests.
Pass courses across a shift change
A long evening may involve several service colleagues. One enters the menu, another releases the main and a third takes payment. Without a shared status, each person must reconstruct the table history verbally. At handover, use visible order and course status and name the decisions still open: which course is ready, which awaits release and which special requests were clarified? The handover should work even when the first person has moved to another table.
Rehearse a handover in the middle of a menu. The colleague taking over should be able to explain the next sensible step without extra coaching. If kitchen has a paper ticket, ask the station for its view too. If service and kitchen disagree, this is the moment to sharpen the terms or process. A small exercise prevents a real menu becoming stuck between owners during a rush.
Recover from an outage without a second course
If a KDS screen or printer briefly fails, the first question is not “How do I resend?” but “What has the station already received?” Check course status and ask kitchen whether preparation has started. Only then choose a temporary route. Otherwise a precautionary repeat can become a second job. The shift should know who makes this check and how the result is recorded.
It would be wrong to promise automatic KDS-to-print switching for every Bonzumo configuration without checking it. Keep a clear manual temporary path and review actual output options during setup. When normal operation resumes, later printouts must be identified as old or new work. Rehearse with a sample menu rather than first trying it in front of guests. A quiet test turns an abstract failure into a manageable sequence.
Assess the menu from the guests view
Guests do not judge printer rules; they experience the meal. Do plates in one course arrive together? Is the next course paced well? Can service explain what is being prepared if asked? A technically tidy route matters only if it supports those questions. For acceptance testing, choose a menu your kitchen really serves and watch where the actual flow differs from the plan.
Record differences precisely. Release may happen too early, the pass may see a special request too late or dessert may arrive at an unexpected station. Do not change everything at once; identify the responsible mapping and repeat that case. Bonzumo should help make the path from table through station and back to guest visible. Improvement comes from service and kitchen learning together, not a longer list of device settings.
Prepare a concrete demonstration
A Bonzumo demonstration needs only a few well-chosen cases: a normal three-course meal, a table with different menus, a delayed course release and a change after release. Have one person in service and one in kitchen follow each step. Place KDS and paper where they would be used in your future operation. You can then judge whether a screen, a ticket or both actually help the team.
After the trial, four decisions should be clear: who releases courses, which station sees each job, where work status is maintained and what happens during an interruption. Device compatibility is checked separately. The result is not a blanket promise for every kitchen; it is a sound starting point for your own process. Guests benefit when service and kitchen mean the same time and the same job, while the team has fewer handovers to untangle.
