A kiosk that was installed correctly and a kiosk that works are two different things, and the gap is discovered on the first busy lunch. Five checks on installation day and five faults that recur afterwards cover almost everything that goes wrong in the first month.
Installation day: five checks, two hours
The order matters, because each check depends on the one before it. Network, then payment, then the printer, then the menu, then the interface. A kiosk that fails at check two should not be taken further until it passes, because the later checks will appear to pass and will be unreliable.
| Check | How to test it | Failure looks like |
|---|---|---|
| 1. Network | Wired connection, fixed address or a reservation; then pull the cable for ten seconds | It reconnects with a different address and the order service cannot find it |
| 2. Payment | One real transaction for a small amount, then a refund of the same transaction | The payment appears on the terminal but not in the order record, or the refund takes a day to appear |
| 3. Printer | Print ten receipts in a row, then look at the tenth | The tenth is faint, or the paper feed stops and the order is taken with no ticket |
| 4. Menu | Mark one item as sold out in the back office, then look at the kiosk | The item still appears. Sold-out states are usually a separate sync from the menu |
| 5. Interface | Watch three first-time users order without help | They hesitate for more than five seconds on the first screen, or ask where to start |
One: network, and why a cable is better than a promise
A kiosk is a fixed asset on a fixed floor position, and it should have a cable. Wireless is acceptable when there is no option, but it introduces two failure modes that are hard to see: a signal that is adequate at noon and marginal at peak when forty phones join the same access point, and roaming behaviour that behaves differently depending on where the customer stands.
If a cable is impossible, use a reservation rather than a static address, and give the kiosk its own SSID or at least its own band. The test in the table matters more than the configuration: pull the cable, wait ten seconds, plug it back, and confirm the address is the same. A kiosk whose address changes on reconnect will lose its connection to the order service at the moment the network recovers, which is confusing in exactly the way that wastes an afternoon.
Two: payment, and the test that is usually skipped
Most installations test a payment. Few test a refund, and the refund is where the problems live, because the refund path runs in the opposite direction through the same integration and often through different code. A kiosk that takes money and cannot return it produces a queue at the counter and a member of staff apologising.
Two further payment details deserve a test on the day. The timeout: what the kiosk does if the payment terminal does not answer. It should show a message within about thirty seconds and cancel cleanly at sixty, and it should never leave the order in a state where the customer has paid and the kitchen has not received it. And the duplicate: pay the same order twice by tapping the button again during processing, and confirm that only one charge exists.
Three: the printer, and the tenth receipt
A thermal printer that prints one receipt perfectly tells you almost nothing. The failure that matters in service is the tenth, twentieth and hundredth, because the head heats up and the density falls. Print ten in a row on installation day and compare the first with the last. A visible difference is a head that will fade during a peak.
The second thing to check is the paper path in the position it will actually occupy. A kiosk whose paper exit points at a wall, or upward into an overhang, will jam on the first curl. Receipt paper has a natural curl from the roll and it needs somewhere to go. The take-up height matters too: a ticket that emerges at knee height is picked up by accident, and one at eye height blocks the screen.
Four: the menu, and the sold-out trap
The single most common first-month complaint about a kiosk is that it sold something the shop had run out of. The cause is that the menu on the kiosk and the menu in the back office are often synchronised by different jobs, or on a schedule that is longer than a lunch service.
The test is direct: mark an item as sold out in the back office, then look at the kiosk. If it is still there, the sync is not live and the shop needs a manual override for the kiosk during service, which is a workflow rather than a technical fix. The workflow that works in most small shops is a printed card on the screen for the three or four items that run out, plus somebody marking them sold out on the kiosk itself if the software allows it.
The related item is the default options. A kiosk that defaults to a large size and an extra shot will sell more of both, which is the point, but it will also produce a complaint from the customer who did not notice. Defaults are a commercial decision and should be set deliberately rather than left at whatever the template had.
Five: the interface, judged by watching three people
The last check is not a configuration item, it is a usability test, and it takes fifteen minutes. Find three people who have never used the kiosk and ask them to order something. Do not help. Write down where they pause.
| What you observe | Usually means | What to change |
|---|---|---|
| They look for a start button | The first screen is a menu, not a prompt | Make the first screen an explicit start |
| They scroll past the categories | Too many categories, or no images | Six to eight categories with photographs |
| They cannot find a modifier | Modifiers are hidden behind a long press | Put modifiers on the item screen as visible options |
| They tap the total expecting to pay | The pay button is not visually dominant | One primary button, large, at the bottom right |
| They ask where the receipt comes from | No indication of the paper exit | A printed arrow, or a light at the slot |
The five faults that keep coming back
Once the kiosk is in service, the same five problems recur across shops. Each has a known cause, and none of them is the hardware being broken.
| Fault | Cause | At the counter |
|---|---|---|
| Stuck on payment | The terminal did not answer and the kiosk has no timeout message | Cancel from the staff screen; report the timeout setting as a configuration fault, not a hardware one |
| Two identical orders | Double tap during processing, or a retry that succeeded twice | Void the duplicate, and check whether the confirm button disables while processing |
| No ticket, order accepted | Paper out or a jam, with no interlock between the printer and the order | Hand the customer a receipt from the counter, and set the kiosk to warn when paper is low |
| Orders missing during a network drop | The kiosk took the order locally and the queue did not flush | Check the offline queue and force a sync; if there is no queue, that is a software gap |
| Touch lands in the wrong place | Cleaning spray on the surface, or a calibration drift | Dry the screen and recalibrate; do not spray directly onto the panel |
The cleaning fault deserves its own line because it happens weekly in every shop that cleans properly. Spray applied directly to the panel runs to the edge and into the bezel, where it leaves a film that changes the capacitance at the edges. The symptom is a touch that works in the middle and misses at the corners, which reads as a failing panel and is actually a cleaning method.
The first week, in order
What to watch, day by day, so that a problem is caught while it is still small.
| When | Watch for | Why then |
|---|---|---|
| Day one, first service | Abandoned orders and where people stop | The first impression is the only one you get with regulars |
| Day two | Receipt paper consumption | It sets the restocking interval and reveals a feed problem early |
| Day three | Any duplicate or missing order | Payment and queue issues surface once volume is normal |
| Day five | Staff workarounds | Whatever staff invented is either a training gap or a design gap, and both are cheap to fix now |
| Day seven | The sold-out problem | One week is enough to see whether the menu sync is live |
The fifth day is the most informative. Staff invent workarounds quickly, and each one is a sentence about the design that nobody wrote down. A shop that collects those five sentences in the first week ends up with a kiosk that people use, rather than one that gets a hand-written sign taped over the screen.
FAQ
How long does kiosk installation take?
Two hours for the five checks, plus a week of watching. The hardware is mounted in under an hour. The payment and menu checks are what take the time, and they are the two that get skipped when installation happens on the morning of opening.
Should the kiosk take cash?
Usually not. A cash acceptor adds a note path, a vault, a jam point and a reconciliation task, and it is the component most likely to be out of service. If cash matters, keep one staffed till for it rather than putting a note acceptor in the kiosk.
Why does the kiosk show an item that is sold out?
Because the kiosk menu and the back-office menu are synchronised by a job that runs on a schedule. Check the sync interval before assuming a bug, and put a manual override in place for the items that sell out during service.
Where to go next
Five checks on the day and five faults afterwards. A kiosk that passes all ten is a kiosk that will still be used in month six.
The throughput and payback arithmetic before buying a kiosk The four hardware decisions on a kiosk Self-service kiosk hardware for retail, hotels and clinics · what a kiosk is, by job · where AI actually pays in a POS workflow
