Before installing a kiosk, test the complete path from the screen to the payment device and kitchen, not just whether the kiosk turns on. Map each device’s power source and network connection, then separately simulate an internet interruption and a power restart. Agree with the vendor on observable pass or fail criteria before the demonstration.
A useful result tells you what happens to a guest’s cart, whether staff can tell if a payment was attempted, and whether an order reached the kitchen. It also tells you when staff must stop using the kiosk and take orders another way. The right arrangement depends on your building, equipment and tolerance for interruption.
Map every dependency before choosing a location
Start with a floor plan. Mark the proposed kiosk, its payment device, the counter POS, kitchen display or printer, router and internet connection. Draw the connections between them, including any Wi-Fi links. Ask the vendor which connections are required for browsing, payment, sending an order and displaying it to the kitchen. Do not assume those steps all use the same path.
For power, identify the outlet and circuit serving each device. A kiosk and router plugged into different outlets may still share a circuit. Ask a qualified electrician to assess the proposed installation, cable routing and any backup-power equipment. Keep cords out of guest paths and away from cleaning water. Check whether the kiosk can be moved for cleaning without straining its cables.
For the network, ask whether the kiosk needs a wired connection, can use Wi-Fi, or supports both in the proposed configuration. A strong signal at the counter does not prove there is a reliable connection at the kiosk. Walls, metal equipment and the distance to the access point can affect placement. Have the installer check the actual spot and explain how the kiosk, payment device and kitchen equipment reach one another.
Next, trace the payment device separately. Ask whether it uses the kiosk’s connection or its own, what power it needs and which device reports its status to staff. A payment terminal with a lit screen is not necessarily ready to accept a payment. The vendor should show how the proposed setup indicates readiness without running a real card.
Finally, identify the kitchen endpoint. If you use restaurant management software or a separate kitchen system, ask exactly how a kiosk order reaches it and what staff see when that link is unavailable. Record the devices and services that must be working for an order to appear in the kitchen.
Use a site worksheet with observable results
The following example is hypothetical. A small restaurant plans one kiosk near its entrance, a payment device at the kiosk and a kitchen display behind the counter. The proposed setup uses the restaurant’s internet connection. The owner has a staffed counter available during service. The vendor and owner must agree on the expected behavior for their actual equipment before using these criteria.
This worksheet is a decision aid, not a promise that every kiosk behaves the same way. A pass means the demonstrated setup meets the written requirement; a fail means staff would not have the information or control they need.
| Check | Expected result | Pass | Fail |
|---|---|---|---|
| Power map | Kiosk, payment device and network equipment have identified sources. | Installer identifies outlets and explains restart dependencies. | A required device or its power source is unaccounted for. |
| Network path | Each required connection is identified at the planned location. | Vendor shows the proposed path and a usable connection there. | The path is unclear or the location cannot maintain the connection needed for the demonstration. |
| Internet interruption | Staff can identify the outage and stop unsafe order attempts. | Status is visible and the agreed fallback can be started. | The screen invites an order while staff cannot establish its status. |
| Power restart | Staff can determine when the setup is ready for use again. | Devices return to the agreed ready state and test order status is clear. | Readiness or the test order’s status remains unclear. |
Write the actual outlet, circuit, connection method and responsible contact beside your copy of the worksheet. Add the agreed behavior for the specific hardware and software in the quote. For example, if the vendor says the kiosk should display an outage message, record where it appears and who can see it. If it only alerts a manager through a separate console, decide whether that is sufficient during a busy shift.
Use the worksheet to identify placement decisions too. A location that looks convenient for guests may need a network cable, a different access point or electrical work. Compare those installation requirements with another location before ordering a kiosk enclosure or scheduling construction.
Test network interruption and power restart separately
Arrange a supervised simulation with the vendor in a test environment. Use a clearly labeled test cart, a simulated payment response and a test kitchen destination. Confirm in advance that the exercise cannot charge a real card, send a guest message or dispatch a courier. It should not create a live kitchen ticket. Have someone record what appears on each screen and the time staff first notice the change.
Simulate an internet interruption
Begin with the test setup in its normal ready state. Add a fictional item to the cart, then have the vendor interrupt the internet connection in the test environment. Do not also remove power: that would make it harder to tell which dependency caused the result.
Observe what the kiosk shows a guest, what the payment device shows and what the counter can see. Try only the vendor-approved simulated steps. The expected result for the example is that staff can recognize the interruption, prevent further unsafe test orders and direct guests to the counter. The exact screen behavior must match the written acceptance criteria.
Restore the connection and ask the vendor to demonstrate how staff determine readiness. Does the kiosk need a manual restart? Does the payment device reconnect independently? Is there a visible status for the kitchen connection? Record each action, the person responsible and any uncertainty. A connection returning is not, by itself, proof that every part of the workflow is ready.
Simulate a power restart
Reset the test environment, then run a separate power-restart exercise under the installer’s direction. Identify which test devices lose power and which remain on. For instance, restarting only the kiosk does not show what happens when the router also loses power. If both situations matter to your site, agree on separate demonstrations.
The example passes if staff can follow the documented restart sequence, see when the relevant devices are ready and establish what happened to the test cart. It fails if the screen returns but staff cannot determine whether a test order was sent. Note any required manual steps, including who has access to restart network equipment. Do not treat a successful simulation as a guarantee that every real outage will follow the same sequence.
Record order state and plan a staffed fallback
After each simulation, record three separate states: cart, payment and kitchen order. They are related, but one does not prove another. A cart may still be visible without an order reaching the kitchen. A payment status may be unclear even if the kiosk displays an error. A kitchen ticket may need checking independently rather than assuming it exists or does not exist.
For the hypothetical test, the acceptance record should identify whether the fictional cart remains visible, disappears or requires staff action. For the simulated payment, record the status shown at the kiosk and payment device; do not call it paid unless the simulated result explicitly says so. For the kitchen, check the designated test destination for the test ticket and note its status. If any state cannot be established, mark that check as a fail and ask the vendor how staff should handle it.
Keep the response simple enough for a shift lead to use. Decide who puts an unavailable kiosk out of use, who checks device status and who tells the kitchen about a test or live issue. Prepare a physical sign directing guests to the counter. Make sure staff know which menu and payment process to use there, and how to tell the kitchen about counter orders.
Your fallback should not depend entirely on the same failed connection. Ask what the counter’s restaurant POS system needs to operate and what staff can safely do if that connection is also unavailable. If the answer is to pause a particular service until systems return, include that in the plan. Do not assume offline payment is available.
Once the simulation meets your criteria, consider a supervised live service pilot with staff ready to direct guests to the counter. Unlike a simulation, a live pilot involves real orders and may involve real payments. Agree on the hours, responsible staff and stop conditions first. Watch for unclear statuses or a fallback that slows the counter, and stop the pilot if staff cannot confidently account for orders.
Compare support and installation commitments
Before signing, ask each vendor for a written description of the proposed hardware, network and power requirements, installation work and support responsibilities. Identify who diagnoses the kiosk, payment device, local network and kitchen connection. A useful support plan names the first contact and explains how the issue is handed off when another provider owns part of the setup.
Ask what help is available during your actual service hours and what information staff should collect before calling. Request the restart procedure and the steps for taking the kiosk out of service. Confirm whether installation, cabling, electrical work, network changes and staff training are included in the quote or priced separately. Also ask about recurring support charges and any charges for a return visit.
Compare the operational quote totals on the same scope. A lower equipment quote can leave more work for the restaurant if it excludes installation or network preparation. For a broader cost review, use the kiosk break-even guide alongside your site worksheet. Ask a qualified adviser about contract terms where needed.
Take your completed dependency map and pass or fail criteria to the vendor demonstration. Compare your requirements with Fleksa’s restaurant kiosk and confirm current availability, compatible equipment and the proposed fallback before choosing a workflow.
Frequently asked questions
Does a restaurant kiosk need a wired internet connection?
That depends on the equipment and configuration. Ask the vendor which connections are supported, then check the proposed kiosk location and the connections needed by the payment and kitchen devices.
Will a kiosk keep taking payments when the internet goes down?
Do not assume it will. Ask the payment and kiosk providers what the specific setup supports and how staff can identify payment status. Plan a staffed alternative if payment availability cannot be established.
Should the kiosk and router share backup power?
That is a site-specific decision. Map every device the workflow needs, ask what each one requires and have a qualified electrician assess any proposed backup-power arrangement. Test the resulting restart procedure with the vendor.
