To check two kiosks, write down the intended settings for each device, then run the same simulated order on both and compare the resulting tickets. Check the location, menu, receipt destination and fulfillment mode—not just what appears on the guest screen. A kiosk is ready only when its results match the settings you intended for that device.
Give one manager responsibility for the final decision. The manager does not need to perform every setup task, but someone must own the matrix, collect the test results and decide whether each kiosk can be used during service. This is an operational configuration check, separate from deciding who has administrator access.
Decide what each kiosk needs to do
Start with the service conditions, not the screens. Two devices in the same dining room may need identical settings. A kiosk near a separate pickup entrance may need a different fulfillment option or receipt destination. A second restaurant location may share a menu name with the first while using a different kitchen.
Walk the order path with the people who handle it. Ask the shift lead where guests will stand, the kitchen lead where orders should appear, and the person responsible for receipts where staff expect to find them. If the restaurant uses a restaurant POS system, include whoever manages its location and order settings.
Set a clear rule for differences. A different destination is acceptable when it is intentional and documented; it is a failure when staff expect both devices to behave alike. Also decide what happens if a menu item is unavailable, a printer stops, or a guest needs help. Those conditions can change whether the setup is workable even when a basic order succeeds.
Before booking a demonstration, ask the vendor which settings are controlled per device, which are controlled by location, and who can change them. Request a walkthrough using your actual service arrangement rather than assuming that two devices can be configured independently.
Build a device matrix before setup
The following is a hypothetical example for one restaurant with two kiosks. Both serve the same location and menu. The front kiosk is intended for dine-in; the pickup kiosk is intended for takeout. The receipt destinations refer to staff order tickets, not a promise about a guest's printed or digital receipt.
| Device | Location | Menu | Ticket destination and fulfillment |
|---|---|---|---|
| Front kiosk | Market Street | All-day menu | Kitchen station A; dine-in |
| Pickup kiosk | Market Street | All-day menu | Kitchen station A; takeout |
The table is the expected result, not proof that either device is configured correctly. If the restaurant also needs a guest receipt, add that expectation to the test record: whether a receipt is offered, how the guest receives it, and whether staff need a copy. Ask the vendor which receipt options are available in the proposed setup.
The manager owns the matrix. The setup lead records the actual device settings against it; the kitchen lead checks the intended ticket destination; and a shift lead confirms that the fulfillment choices make sense to guests. Record the device name or another reliable identifier so staff do not confuse two matching screens.
Keep the matrix accessible to the people who maintain the system. Review it after a menu change, a device move, a new service mode or a change to ticket routing. A kiosk can be physically in the right place and still be assigned to the wrong restaurant location.
Compare setup approaches and operating costs
Use the matrix to compare a shared configuration with separate device settings. A shared setup may take less staff time to maintain when both kiosks genuinely need the same menu, destination and fulfillment choices. But it can create guest confusion if one device needs different options. Ask whether a change to a shared menu or setting affects both devices, and how staff can verify the result.
Separate settings may suit devices with different service roles. The tradeoff is more to check: staff must know which changes apply to one device and which affect the whole location. Ask the vendor to demonstrate the exact differences you need and show how an authorized employee would update them. Do not treat a device-specific setup as available until it has been demonstrated for your configuration.
For either approach, compare the guest experience as well as the back-office work. Can a guest find the right service choice without staff help? What does a guest see when an item is unavailable? Can staff identify which kiosk produced an order that needs attention? Check accessibility and the physical space around both devices, including room for a guest who needs assistance.
Request a written quote covering hardware, software, installation and payment compatibility. Ask which charges are fixed, which vary with use, and what support or replacement costs might arise when something fails. A processing quote alone is not the all-in operating cost. Also ask whether the proposed hardware is supported; compatibility should be confirmed for the devices and payment equipment you intend to use.
Compare the quote with the time staff will spend maintaining the configuration and helping guests. The kiosk break-even guide can help frame that broader decision. A lower setup quote is not necessarily the better operating choice if staff must repeatedly correct orders or move tickets by hand.
Run a safe pass-or-fail order comparison
Use the hypothetical matrix above to define the test. On each kiosk, enter the same item and the same permitted customization. Select dine-in at the front device and takeout at the pickup device, because those are the intended differences. Keep the item and customization identical so the resulting tickets are easier to compare.
Run this as a simulation with the vendor or setup lead. It must not charge a real card, send a message to a guest or dispatch a courier. Confirm that the test environment also prevents real kitchen tickets or other live operational actions. If the vendor cannot provide a safe simulation, ask for a controlled demonstration of the order path instead; do not submit a live order and assume it will be harmless.
For each device, record what was selected on screen and retain the simulated output the system provides, such as a ticket preview or test record. The setup lead captures the results, the kitchen lead checks the ticket details, and the manager compares both records with the matrix. Check these points:
- Location: Both results identify Market Street, not another restaurant.
- Menu and item: Both show the same item and customization entered in the simulation.
- Destination: Both route to the expected simulated destination for kitchen station A.
- Fulfillment: The front result says dine-in; the pickup result says takeout.
- Receipt: The simulated receipt behavior matches the restaurant's documented expectation, where that behavior can be simulated.
Suppose the front result matches every expected field, but the pickup result shows dine-in. The front kiosk passes this comparison; the pickup kiosk fails. The manager should not approve the pickup kiosk for its intended role yet. Ask the setup lead to correct the setting, then repeat the comparison and keep the new results with the matrix.
Next, simulate exceptions relevant to the restaurant: an unavailable item, a destination that cannot receive a ticket, or a guest who needs to change a selection. Ask what staff see and what action they must take. Do not assume the system will reroute an order or recover a payment. If a required behavior cannot be demonstrated, decide whether the manual fallback is acceptable before purchasing.
A fallback might be to pause the affected kiosk, direct guests to a staffed register and have the shift lead notify the kitchen of the change. Give staff a clear way to identify a kiosk as unavailable and a named person to contact. If the fallback requires staff to re-enter an order, specify how they will check for an existing order first.
Simulation is not a live service pilot. After the simulated checks pass, the manager can plan a separately supervised pilot during a manageable service period, with staff ready to use the fallback. Review actual order handling and guest questions before expanding use. This reduces uncertainty, but it does not guarantee uninterrupted service.
Compare the matrix with your current workflow, then ask Fleksa to demonstrate the applicable restaurant kiosk capabilities for both devices. Bring the expected settings, exception list and written quote questions. You can also review the kiosk documentation before the discussion.
Frequently asked questions
Should both kiosks always use the same settings?
No. They should match when their service roles match. Document any intended differences, such as dine-in versus takeout, and confirm that the proposed setup supports them.
What if the two test tickets do not match?
Compare each result with the matrix rather than assuming the tickets should be identical. Correct any unintended difference and repeat the safe simulation before approving the affected device.
Does a successful simulation replace a live service pilot?
No. A simulation checks defined behaviors without real payments, guest messages or courier dispatch. A separately supervised pilot shows how the workflow operates with staff and guests during service.
