Upgrade kitchen displays with a named shift owner, a device-by-device plan and a clear way to stop. Whenever possible, do the work between services. If a screen must change while the kitchen is active, upgrade one device at a time only after the vendor confirms that the old and new versions can work together.
The goal is to protect the order flow while staff learn what has changed. That means checking where tickets come from, where they appear and what happens when a cook marks work complete. Keep a practical backup workflow ready, and do not assume an upgrade can be reversed until the vendor explains how.
Inventory every screen and its dependencies
Start with a walk through the kitchen. Record each physical display, its station, device model, current software version and the version you plan to install. Include the expeditor screen and any spare device, not just the screens cooks use most often. Give each device a name staff will recognize, such as Grill or Pass.
Next, map the orders and actions that touch each screen. Which ordering channels feed the kitchen? Which stations need to see an item with a side or modifier? Does the pass depend on a completion action at a prep station? A short conversation with the cook and expeditor at each position can reveal dependencies that are easy to miss from the office.
Ask the vendor to confirm the device requirements, supported upgrade path and whether the current and new versions can run together. Also ask whether the POS, ordering tools, network equipment or station settings need changes at the same time. If the vendor cannot support mixed versions, do not plan a screen-by-screen live-service rollout.
The following is a hypothetical example for a restaurant with three physical screens. It is an operational sequence, not a claim about a particular product. The shift owner would replace these entries with the restaurant's actual devices and the vendor's confirmed instructions.
| Device | Dependency to check | Sequence | Decision before continuing |
|---|---|---|---|
| Grill | Grill items and modifiers reach the cook. | Upgrade first during the break. | Confirm the sample ticket and completion behavior. |
| Cold prep | Items for both stations stay visible where needed. | Upgrade second. | Confirm both screens show their intended portions. |
| Pass | Expeditor can see the order and understand station progress. | Upgrade last. | Confirm the agreed end-to-end ticket check. |
The table puts the pass last because the example owner wants to keep its existing view available while the prep screens change. That order is suitable only if the vendor confirms the versions can coexist and the pass can work with them. Otherwise, schedule the connected devices together outside service. For more on mapping stations before making that decision, see the guide to routing kitchen tickets by preparation station.
Choose a window and name the shift owner
A quiet break between services is usually the simpler choice. Staff can check each device without juggling live tickets, and there is time to resolve an unexpected setting before the next rush. Ask the vendor how long to allow for installation, checks and a possible rollback. Add time for the team to review the result; the download time alone is not the whole window.
A phased upgrade may be useful when a long break is unavailable and the vendor supports mixed versions. It still carries service risk. The person running the rollout must be able to pause after each screen, and the kitchen needs a way to handle orders while that screen is being changed. Avoid starting just before a predictable rush or when a key station is short-staffed.
Name one shift owner before the work begins. That person does not need to perform every technical step, but should have authority to stop the rollout, contact the vendor and tell the kitchen which workflow is in use. Name a backup in case the owner is pulled into service. Identify one cook or expeditor to check each station, and agree on a short phrase such as “Grill check complete” so nobody mistakes installation for operational approval.
Before the window, put the vendor's support contact, device list, upgrade instructions and rollback steps where the shift owner can find them. Decide how staff will record and communicate live orders if a screen cannot be used. For example, a designated person might write orders on paper and call them to stations, with the expeditor tracking completion. Practice the handoff so the team knows who owns each ticket; a paper pad alone is not a complete fallback.
Rehearse with a safe sample ticket
Use a vendor-supported training environment for the first rehearsal. Confirm that the sample cannot create a real charge, send a guest message or dispatch a courier. If the vendor cannot isolate those actions, ask for another safe demonstration method before creating the sample. Do not use a real guest order as a practice ticket.
Build one sample that follows a normal but useful kitchen path: a main item for the grill, a side for cold prep and a modifier the cook must see. Give the staff checking it the expected result before they look at the screens. That makes it easier to spot an item that is missing, duplicated or visible at the wrong station.
- Send the simulated order and check the item names, quantities and modifier at each intended station.
- Compare the upgraded screen with any screens still on the earlier version, if the vendor supports that configuration. Confirm each shows the portion staff expect.
- Have the appropriate cook mark the sample work complete. Check what the other station and expeditor see against the restaurant's agreed workflow.
- Ask the vendor to demonstrate any other action the team relies on, such as changing or canceling an order. Do not assume every system handles those actions in the same way.
- Record the result against the device name and stop if a required check fails. Repeat the relevant checks after the next device is upgraded.
Agree on expected behavior before the rehearsal. For example, if the pass needs to know when both stations are finished, write down what staff should see and who verifies it. A visible ticket is not enough if the modifier is missing or the expeditor cannot tell what is ready.
After the simulated checks pass, use a supervised service period to observe the normal flow. This is a live pilot, not another simulation: genuine orders should be handled through the restaurant's ordinary process, with the shift owner watching for problems and ready to switch to the agreed fallback. Do not create artificial guest orders, payments, messages or courier requests for the pilot.
If you are comparing products or preparing questions for a current provider, review the kitchen display documentation alongside your own station map. Ask the provider to demonstrate the exact workflow your kitchen needs rather than relying on a feature name alone.
Set stop, rollback and escalation rules
Write the stop criteria before the first device changes. Stop the rollout if a required item or modifier is missing, a ticket appears at the wrong station, the agreed completion check fails, or staff cannot reliably tell which workflow is active. Also stop if the work runs into the service period without the planned checks being complete. The shift owner should announce the pause and prevent anyone from upgrading the next device.
A stop does not automatically mean reinstalling the old version. Ask the vendor in advance whether rollback is supported, what it affects and who must perform it. Record the previous version and any settings needed to restore the agreed configuration. If rollback is unavailable or would create more uncertainty, use the agreed fallback and contact support rather than improvising during a rush.
Give the shift owner a clear escalation trigger: contact the vendor when a required ticket check fails, an unexpected version or device issue appears, or the team cannot safely return to its normal workflow. Share the device name, versions, time of the change, the failed check and what staff are seeing. Keep guest and payment information out of support messages unless the provider specifically requires it and supplies an appropriate way to share it.
Resume the rollout only when the shift owner and the relevant station checker can repeat the failed check successfully, or when the vendor has provided another workable plan that the kitchen understands. After service, note what changed, what remains on the old version and who will finish any outstanding work. That handoff matters if a different manager opens the next shift.
As a next step, take your screen inventory and sample ticket to a provider demonstration. Compare Fleksa's kitchen display system with your station workflow and ask about current availability, device requirements, supported training and rollback for your setup.
Frequently asked questions
Can I upgrade one kitchen screen during service?
Possibly, if the vendor supports the old and new versions working together and your team has a safe fallback. A break between services gives you more room to check the result without live tickets competing for attention.
What should a kitchen display test ticket include?
Use a simulated order with items for the relevant stations, quantities and at least one meaningful modifier. Check visibility and the completion workflow in a vendor-supported training environment without triggering a real payment, guest message or courier dispatch.
Who decides whether to roll back an upgrade?
Assign a shift owner to stop the rollout and coordinate the decision. Confirm the rollback procedure with the vendor beforehand; if reversal is not supported or cannot be done safely, use the agreed fallback and escalate.
