A safe lunch-to-dinner kitchen display switch starts with one rule: an unfinished ticket must remain visible to the person responsible for completing it. Before changing stations or filters, name a switch owner, account for open work and test what happens to that work in the intended dinner configuration.
If the display cannot keep the ticket visible to its owner, do not rely on the switch as configured. Keep the lunch layout in place until the work is complete, or use a written handoff that the receiving cook acknowledges. The right choice depends on your service pattern and what the vendor can demonstrate.
Decide who switches and when
Assign one person, usually the kitchen manager or expeditor, to authorize the change. That person checks the open-ticket list, tells station owners what will change and confirms the dinner view is ready. Cooks still own their assigned food; the switch owner owns the handoff between views.
Pick a transition window based on the kitchen, not just the clock. A quiet gap after the lunch rush may allow time to finish outstanding tickets. A restaurant with continuous orders may need overlapping station coverage or a deliberate handoff instead. Consider whether the same cooks work both services, whether dinner adds a station and whether orders scheduled for later could appear during the change.
Set a stop condition before service. For example: do not switch while an open ticket has no named owner, a cook cannot see assigned work, or the team cannot agree on a fallback. A manager can delay the change or keep a single layout for both services. Make sure the front-of-house lead knows if the delay affects order flow.
Start by mapping your existing kitchen ticket routing by preparation station. The transition decision is narrower: what happens to work already in progress when that routing or its visible filters change?
Map the change before touching the display
The following worksheet is hypothetical. A restaurant uses a grill station and a shared cold station at lunch. At dinner, it plans to split the cold work between a salad cook and a dessert cook. One lunch salad ticket remains open when the change is due.
The table records the intended state, not a promise about any product. The kitchen manager owns the overall switch; each cook confirms the work assigned to that station.
| Check | Before: lunch | After: intended dinner | Owner and decision |
|---|---|---|---|
| Station layout | Grill and shared cold | Grill, salad and dessert | Manager confirms each staffed position. |
| Visible filters | Cold cook sees assigned cold work. | Salad cook sees salad work; dessert cook sees dessert work. | Each cook confirms the actual view. |
| Open lunch ticket | One salad ticket is open and owned by the cold cook. | It stays visible to that cook, or ownership is explicitly handed to the salad cook. | Manager identifies the owner and confirms acknowledgment. |
| New dinner work | Dinner layout is not active. | New work appears at the intended staffed station. | Manager checks the view before relying on it. |
Before the switch, the manager records the ticket identifier, its items and modifiers, its status and the responsible cook. The manager also checks for other unfinished tickets and future orders that may need attention. A count alone is not enough: the team needs to know where each ticket belongs.
After the switch, the manager compares the views with that record. If the original cold cook still owns the salad ticket, that cook must still be able to see it. If the team transfers ownership, the salad cook must acknowledge the ticket and see the relevant details. Merely telling the new cook that a ticket exists is not a completed handoff.
Write down the actual station names and filters used in your restaurant. Ask the vendor whether changing a filter affects only the local view or also changes where tickets are routed. Those are different actions, and either can affect who sees an unfinished order.
Choose an approach your team can operate
There are three practical approaches to compare. A single layout for both services reduces configuration changes, but a dinner cook may have to sort through more work on a shared screen. Finishing lunch work before changing layouts creates a clear boundary, but may delay the dinner setup. Switching with tickets still open can suit continuous service, provided visibility and ownership are demonstrated and the team can handle exceptions.
Compare them using the same service scenario rather than a list of feature names:
- Staff effort: Who changes settings, checks tickets and confirms the handoff? Can that person do it during your busiest overlap?
- Guest impact: What happens if a ticket is missed or preparation is delayed? Decide who tells the front-of-house lead when the kitchen needs extra time.
- Cost dependencies: Ask for an operational quote covering the displays, software, setup and training needed for the chosen layout. Separate fixed charges from usage-based charges, and ask what an extra screen or configuration change would cost.
- Limits: Ask which changes staff can make themselves and which require vendor help. Check device compatibility and what happens if a screen or connection fails.
A cheaper configuration is not automatically the better choice if it leaves one cook monitoring several views during a rush. Equally, an additional display is only useful if it gives a staffed station a clear responsibility. Compare written quote totals on the same scope, including any exception charges the vendor identifies.
Square describes kitchen tickets, timers, station routing and expeditor functions for its KDS. Toast offers a kitchen display product. Fleksa offers a kitchen display system linked to restaurant orders. For each option, ask for the same open-ticket demonstration; do not assume that a named feature behaves the way your transition requires.
Fleksa's published display information includes order type, item names, quantities, modifiers, future held orders and configurable timing or color indications. Ask which of those details appear in each proposed station view and how your setup handles a configuration change. For current Fleksa pricing, see the plans page; pricing information was checked in November 2026. Confirm the equipment and services included in your own quote.
Run the open-ticket test before selection
Ask each vendor to run the same scenario in a vendor-supported training environment. Use simulated orders only. The practice must not take a real card payment, send a guest message or dispatch a courier. Have the intended switch owner and station cooks watch the demonstration, so the test checks both the display and the handoff they would actually perform.
- Set lunch views. Identify the stations, active filters and cook responsible for each simulated ticket. Create a simulated lunch ticket with an item and modifier, and leave it open.
- Record the starting state. Note the ticket identifier, visible details, status, owner and screen where the owner can see it. Record other open simulated tickets too.
- Change to the intended dinner configuration. Use the steps the vendor says your staff would use. Do not complete the lunch ticket just to make the switch easier.
- Check ownership and visibility. Confirm that the lunch ticket remains open and visible to its owner with the information needed to prepare it. If ownership must change, require an explicit acknowledgment from the receiving cook and check that cook's view.
- Check new work and exceptions. Add a simulated dinner ticket and confirm it appears at the intended staffed station. Ask how a changed or canceled order would be shown, and what staff should do if a display goes down. Do not assume recall or rerouting is available.
Pass only if the open lunch ticket remains visible to its acknowledged owner, its needed details remain available, and new simulated dinner work appears where the team expects it. Record the steps, observed views, ticket status and any manual handoff. A screenshot or a written observation can help the team compare demonstrations; neither replaces a cook confirming the view.
In the hypothetical worksheet, suppose the salad ticket disappears from the cold cook's view after the dinner filters are applied, and the salad cook has not accepted it. That is a fail. The manager should not use that switch procedure with open tickets. The practical decision is to finish or explicitly hand off the lunch work before changing views, then confirm the dinner stations. If neither is workable during the restaurant's overlap, retain the shared layout while asking the vendor for another demonstrated setup.
After a successful simulation, plan a supervised live service period with the manager watching the actual transition and a clear stop condition. Real orders should follow the restaurant's normal process, not be created merely to test the system. If the live views or handoff do not match the demonstrated procedure, stop the change and use the agreed fallback.
Compare this workflow with your current process, then ask Fleksa to demonstrate the applicable capabilities of its restaurant POS system and kitchen display using your station map and open-ticket scenario.
Frequently asked questions
Should the kitchen switch displays at a fixed time?
A target time helps staff prepare, but open work and staffing should determine whether the switch is safe. Give the switch owner authority to delay it when a ticket lacks a visible, acknowledged owner.
What if an open ticket disappears after a filter change?
Treat the test as failed. Restore the agreed working view if possible, account for the ticket and assign an acknowledged owner. Ask the vendor to demonstrate a workable procedure before relying on that configuration change.
Can one display layout work for both services?
It can be a practical choice when the same stations handle both menus and cooks can identify their work. Check that the shared view stays readable during the busiest overlap and that every ticket has an owner.
