If internet access fails but your restaurant’s local network still works, an order can reach the kitchen screen only if every part of its path can operate without the internet. An order entered on a local POS may qualify, but only if the POS, order service and kitchen display are designed and configured to exchange it locally. A remote order generally needs an internet connection to get into the restaurant first.
Do not buy on the strength of an “offline mode” label alone. Ask the vendor to show which order sources work, what the kitchen sees and what happens when the connection returns. A screen that stays lit is not proof that a new ticket can reach it.
Map the route from order to screen
Start with the equipment and services involved in each order. A simple in-store path might be: staff POS terminal → local network → order service → kitchen screen. The important question is where that order service runs. If a cloud service must receive and return the order before the screen can display it, a working Wi-Fi network inside the restaurant may not be enough.
A remote path has an extra boundary: guest device or ordering service → internet → restaurant order service → kitchen screen. Even if the guest can place an order elsewhere, that does not mean it has reached your restaurant or that the kitchen has received it. Ask where the order waits and how staff will know it is waiting.
Separate the internet connection from the local network in your notes. A router and local devices can remain connected to each other while the restaurant’s internet service is down. Conversely, an internet outage is a different problem from a failed router, a disconnected screen or a power outage. The test below addresses internet loss with the local network still working; it does not establish what happens in those other failures.
List every order entry point you use: staff POS, kiosk, QR ordering, direct online ordering and any third-party ordering source. For each one, ask the vendor to identify the devices, local services and external services needed before a ticket appears. A restaurant POS system and a kitchen display system may be connected in several ways, so the actual setup matters more than a generic network diagram.
Compare order paths with a practical worksheet
The following is a hypothetical restaurant, not a description of Fleksa or a promise about any product. It has a staff POS, one kitchen screen and an online ordering channel. Its buyer wants to know whether the kitchen can keep receiving in-store tickets during internet loss and how remote orders will be handled.
| Order path | Question during internet loss | Acceptance target |
|---|---|---|
| Staff POS to kitchen screen | Can a new order travel locally without a cloud round trip? | A simulated ticket with its items and modifiers appears once on the intended screen. |
| Guest online order to restaurant | Is ordering paused, or can an order wait outside the restaurant? | Vendor shows the configured behavior and how staff identify any waiting order after reconnection. |
| Existing kitchen ticket | Can staff still view and update a ticket already on screen? | Vendor demonstrates the actions the restaurant needs and whether updates persist after reconnection. |
| Connection restored | How are local changes and any waiting orders reconciled? | Staff can account for each simulated order and identify duplicates or conflicts before acting. |
The acceptance targets are the hypothetical buyer’s requirements, not assumed features. If local entry cannot meet the first target, the owner has a choice: select a setup that can demonstrate it, or plan a manual kitchen-ticket process during an outage. If remote ordering cannot be paused or clearly accounted for, the owner must decide whether the risk of an unseen order is acceptable and what staff should do about it.
Also decide which ticket details are essential. An item name without its modifier may be insufficient for preparation. If the kitchen needs quantities, modifiers, order type or a preparation station, include those in the demonstration. Fleksa’s kitchen display page describes order type, item names, quantities and modifiers, along with held orders and timing indications; ask to see how the features relevant to your setup behave during an outage.
Run separate local and remote simulations
Before the demonstration, agree on the expected result for each scenario and who will record it. Use a vendor-supported training environment with simulated orders. Confirm that the setup cannot take a real payment, send a guest message or dispatch a courier. Do not use an actual guest order as a test.
- Establish the normal path. With internet and the local network available, enter a simulated in-store order with a modifier. Record the order identifier, entry time and screen where it appears. Check that the details match.
- Isolate internet access. Have the vendor or network administrator disconnect internet access for the test environment while keeping the POS and screen connected to the local network. Confirm the local devices can still communicate as the vendor expects. Do not disconnect the restaurant’s live service for an improvised test.
- Enter a new local order. Use a different simulated order identifier and modifier. Look for a ticket on the intended screen. Record whether it arrives, whether the details are complete and whether staff receive a useful warning if it does not.
- Check an existing ticket. Try the kitchen actions your staff need, such as marking an item or ticket complete, if the setup offers them. Record which actions are available and whether the screen shows their status clearly.
- Check the remote path separately. In the training environment, ask the vendor to simulate a remote order or demonstrate what a guest would encounter while the restaurant connection is unavailable. Record whether ordering stops, the order waits elsewhere or another result occurs. Do not assume a waiting order has reached the kitchen.
For a pass, the local ticket must meet the agreed target, not merely appear eventually under unspecified conditions. If it arrives without its modifier, appears on the wrong screen or appears twice, record that as a miss against the hypothetical restaurant’s target. For the remote path, the result may be a supported pause rather than a ticket on screen. The key is that the behavior is known and staff have a workable response.
Ask about other paths separately. A kiosk on the same premises may still depend on an external service; a QR order from a guest’s phone may follow a different route from a staff-entered order. Being physically inside the restaurant does not establish that an order is local.
Agree on recovery and reconciliation before buying
Reconnect the test environment and watch what happens without entering the same simulated orders again. Compare the POS record, kitchen screen and any remote-order queue using the identifiers recorded during the test. Count each ticket once, check its contents and compare any completion status changed during the outage.
For the hypothetical buyer, a satisfactory recovery means staff can account for the local test order, the earlier ticket and the simulated remote order or its documented pause. If a ticket appears twice, a status is overwritten or a waiting order arrives without a clear indication, the team should be able to identify the discrepancy before preparing or repeating it. Ask the vendor to show the available controls; do not assume every screen supports recall, rerouting or cancellation handling.
Put the result in a short buying record: setup demonstrated, order source, expected behavior, observed behavior and any staff action needed. Include who can see a waiting order, who decides whether to prepare it and how a duplicate is flagged. Ask what happens to held future orders and changes made on different devices if those workflows matter to your restaurant.
If the system does not meet a requirement, ask whether a different configuration can meet it and request another demonstration. Otherwise, write down the manual alternative: who takes an in-store order, how the kitchen receives it and who checks it against system records later. Keep payment handling separate from ticket delivery; a kitchen screen receiving an order does not establish that a payment can be processed offline.
After the simulated checks, train staff on the chosen procedure. A supervised live service pilot is a separate step, conducted with normal guest safeguards and without deliberately creating test payments, messages or dispatches. It can reveal whether staff understand their roles, but it should not replace the controlled outage simulation or guarantee uninterrupted service.
Bring your completed order-path worksheet to a vendor demonstration. Compare your requirements with the workflows available from Fleksa, and ask to see the specific behavior in your intended restaurant software setup.
Frequently asked questions
Does working restaurant Wi-Fi mean the kitchen screen works offline?
No. Wi-Fi may connect local devices, but the order path may still require an internet service. Test a new ticket with internet access isolated and the local network working.
Can an online order reach the kitchen during an internet outage?
It depends on the ordering path and where the connection has failed. Ask whether ordering pauses or orders wait elsewhere, and how staff find and reconcile any waiting orders after reconnection.
What should I record in an outage demonstration?
Record the setup, order source, identifier, expected and observed ticket details, available staff actions and the result after reconnection. Include any manual step the team would need during service.
