Before buying a restaurant kiosk, ask who fixes each part, how quickly a usable replacement can arrive, what you will pay, and who restores the ordering setup. Get those answers in writing for the screen, payment reader, mount and software—not just for the kiosk as a whole.
Then compare the vendor’s promises with your busiest service period. A replacement shipped on Monday may not help a restaurant that loses its kiosk on Friday night. Your decision should account for the staffed fallback as well as the hardware bill.
Start with the parts that can stop an order
A kiosk has several possible points of failure. List the parts in your quote and ask who owns and supports each one. The answer may be different for a purchased screen, a leased payment reader and a mount installed by a contractor.
- Screen or computer: What happens if the display will not turn on, touch input fails or the device repeatedly restarts? Ask whether the vendor repairs the unit, exchanges it or directs you to the manufacturer.
- Payment reader: If the reader fails but the screen still works, can a guest complete the order at a staffed register? Ask who supplies a compatible replacement and who configures it. Do not assume another reader will work with your setup.
- Mount and cables: A loose mount, damaged cable or failed power supply can put an otherwise working kiosk out of service. Ask whether diagnosis, parts and an on-site visit are included, and who can safely remove and reinstall the unit.
- Connection or software: Ask how support will distinguish a device problem from a network, account or menu problem. Find out which party takes the lead if more than one supplier is involved.
For each scenario, write down the guest-facing fallback. Can an employee take the order at the counter? How will the kitchen receive it? Your restaurant POS system and kitchen display system may be part of that workflow, so ask the vendors to show how orders reach the kitchen when the kiosk is unavailable.
Also consider where guests will queue and whether they can comfortably use the fallback. A kiosk that is offline during a quiet afternoon creates a different problem from one that fails as the dinner line forms.
Put replacement promises into the quote
A warranty tells you something about covered defects, but it does not necessarily tell you when you will have a working kiosk again. Ask for the warranty period and exclusions for each component. Check what happens after coverage expires and whether an exchange unit is new, refurbished or unspecified.
Separate these four questions when comparing offers:
- Response: When can you reach support, and how quickly will someone acknowledge the issue? Ask whether weekend and evening service is included.
- Diagnosis: What checks must your team perform before the vendor approves a repair or exchange? Ask who decides whether the screen, reader or connection is at fault.
- Replacement: Is a compatible spare held in stock? When does the shipping clock start, and is there an on-site option? A response commitment is not the same as a restoration commitment.
- Charges: Who pays for shipping, labor, parts and return packaging? Ask about deposits, charges for a missing return and fees for damage outside warranty coverage.
Request an example timeline for a failure reported at your busiest time. If a vendor cannot commit to a repair or delivery window, use the timing they provide as a planning assumption, not a promise. Ask what escalation path is available when the first estimate slips.
Finally, check whether you may keep your own spare and what it must match. A spare screen is not much help if it cannot run your configuration or connect to the approved payment reader. Ask for the exact components and setup steps required, along with their quoted costs.
Compare a hypothetical week of downtime
The following example is hypothetical. It compares two operational responses to one screen failure over a seven-day period. The amounts are illustrations, not vendor prices or claims about Fleksa. Assume the restaurant can take every affected order at the counter, but needs extra staff time there. The example measures response costs only; it does not estimate sales, payment processing or the value of lost guests.
The table includes a fixed charge, variable staff coverage and an exception charge for each alternative. Staff coverage is shown at an assumed $20 per hour. The replacement option requires four hours of coverage; waiting for repair requires twelve. The exception charges cover shipping in the first case and a return trip by a technician in the second.
| Cost or outcome | Replacement unit | Wait for repair |
|---|---|---|
| Fixed charge | $180 exchange charge | $80 repair charge |
| Variable staff coverage | 4 hours × $20 = $80 | 12 hours × $20 = $240 |
| Exception charge | $30 shipping | $40 technician return trip |
| Total for the week | $290 | $360 |
Under these assumptions, the replacement costs $70 less for the week, even though its fixed charge is higher. That conclusion depends on the replacement being ready after four hours of counter coverage. If it takes longer, recalculate the staff hours before choosing.
Neither total includes the original kiosk purchase, ongoing software charges, payment fees, taxes, deposits or any longer-term costs. A refundable deposit would affect cash needed during the exchange, but it should not be added to the final cost as though it were a fee. Ask whether a deposit is required, when it is returned and what deductions could apply.
For your own comparison, use the same outage window and the same staff cost on both sides. Add any quoted installation, packaging, travel or after-hours charges. If the fallback cannot handle your normal volume, record that limitation separately rather than inventing a sales figure. For the broader purchase decision, see the related buying guide on kiosk break-even.
Assign the work of getting back online
Delivery of a box does not finish the job. Before signing, name the person or company responsible for each step between a failure report and a usable kiosk. Include a backup contact for hours when the manager is away.
- Remove and connect: Who disconnects the old device, fits the replacement to the mount and connects power and the network? Is a technician required, and what does that visit cost?
- Restore the menu: Who signs in and restores current items, prices, modifiers and availability? Ask what information your team must supply and how a change made during the outage is carried over.
- Reconnect payment: Who pairs and configures the approved reader? What happens if the replacement screen and existing reader do not communicate?
- Check order routing: Who verifies that an order reaches the correct counter or kitchen workflow, with its modifiers intact?
- Return the failed part: Who packs it, supplies a label and tracks the return deadline? Record any deposit or late-return charge separately.
Keep these answers in a short incident sheet near the manager’s station. Add support numbers, account details stored through your normal secure process, operating hours and the fallback procedure. Do not put passwords on a public-facing device or an open sheet.
Ask the vendor to explain what your team can do without support and what requires vendor access. If menu restoration depends on a particular person or account, arrange a backup before that person is unavailable.
Agree on an acceptance check before purchase
Ask for a demonstration of the replacement procedure using a simulated or practice environment. The simulation must not create a real card payment, send a guest message or dispatch a courier. If the vendor cannot provide a safe way to simulate a step, record it as unverified and agree on another safe demonstration.
Use this practical acceptance record for a screen replacement:
- Starting condition: Treat the original screen as unavailable. Identify the compatible replacement, reader, cables and mount before starting.
- Assignment: Record who connects the hardware, restores the menu and configures the reader. Note any support access or credentials needed.
- Menu check: Confirm that a current item, a modifier and an unavailable item appear as expected in the practice environment.
- Order check: Enter a simulated order with a modifier. Confirm that the intended kitchen or counter view receives the same item and modifier, without creating a live order.
- Payment check: Demonstrate the reader connection and a simulated payment response where available. Do not run a real card charge.
- Record: Write down elapsed setup time, missing steps, who resolved them and any charges that would apply to a real incident.
Agree that the check passes only when the assigned people can complete the applicable steps, the menu is correct and the simulated order reaches the intended destination with its modifier. A missing payment simulation should remain an open item, not be marked as a pass. Use the recorded time to assess your fallback plan, not as a guarantee of future restoration time.
If you later run a live service pilot, plan it separately from the simulation. Brief staff, define when to switch to the counter and make sure actual guest orders and payments are handled through the agreed live workflow. A pilot can expose service issues, but it cannot guarantee uninterrupted operation.
Next step: Send your failure scenarios and acceptance record to each vendor with a request for written replacement terms. Then compare your requirements with the workflows available from the Fleksa restaurant kiosk.
Frequently asked questions
Does a kiosk warranty cover a replacement unit?
Not necessarily. Ask whether a covered failure leads to repair or exchange, who pays shipping and labor, and when a usable unit is expected to arrive.
Should a restaurant keep a spare kiosk?
Compare the quoted spare and setup costs with your fallback staffing and expected wait for vendor support. Confirm that the spare works with your mount, software and approved payment reader before relying on it.
What should staff do while a kiosk is down?
Use a documented counter-ordering fallback, direct guests to it and confirm how orders reach the kitchen. Assign someone to contact support and keep the team updated on the expected next step.



