A cashier should be able to search kiosk orders by order number and, when that number is missing, narrow the list by an approximate time. The result should show enough order detail and status to identify a likely match without asking the guest for unnecessary personal information. Just as important, it should make uncertainty visible: two similar orders are not a safe match merely because they appeared close together.
The owner or general manager should decide what evidence staff need before acting on a match. Involve the cashier who will use the screen and the person responsible for resolving payment or order exceptions. A missed lookup can leave a guest waiting while staff search multiple screens; an overconfident one can lead staff to discuss or change the wrong order.
Choose what the cashier needs to see
Start with the guest’s actual question: “Can you find my order?” The cashier needs a short path from that question to a specific transaction, not unrestricted access to every guest detail. Ask vendors to show the search results and the individual order view, including how a cashier moves between them.
A useful result may include the order number, time, items and modifications, amount, payment status and current order status. The screen should make clear what each status means. For example, a record of an order being placed is not necessarily proof that payment was completed. Ask whether the displayed time is when the order was started, submitted or paid; that distinction matters when a guest remembers only when they arrived.
Cashiers also need to know what they are allowed to do after finding a record. Can they only view it, or can they correct it, cancel it or request help? Ask how access is controlled and how a manager reviews an action. The right answer depends on your workflow, but the screen should not encourage a cashier to make a change before the match is established.
Keep the scope of the decision narrow. Finding an order is separate from deciding who prepares, hands over or refunds it. Once the cashier has identified the record, your existing service procedure can determine the next step.
Compare number lookup with time lookup
An order number is a strong starting point when the guest has one and can read it accurately. The cashier can search for the number, then confirm a non-sensitive detail such as an item or modification before discussing the record. Ask where the number appears to the guest and whether a cashier can search it exactly. A number is less useful if the guest never received it, cannot find it or copied a digit incorrectly.
Time lookup is the fallback when the number is unavailable. The cashier asks roughly when the guest submitted the order and what they ordered, then reviews candidates in that window. This can work without collecting a name, phone number or payment-card details. It becomes less reliable during a rush, when several guests may place similar orders within minutes.
The worksheet below compares the two approaches and the decision each supports. Use it during a demonstration, then record your own restaurant’s pass or fail against the final section.
| Lookup | Starting evidence | What to confirm | When to stop |
|---|---|---|---|
| Order number | Number supplied by the guest | An item or modification and the displayed order details agree | No result, conflicting details or uncertainty about the number |
| Approximate time | Guest’s estimated submission time | A distinctive item or modification separates one candidate from the others | Several candidates still fit, or the relevant time meaning is unclear |
| Manual recovery | No reliable match from the screen | Manager checks available evidence using the restaurant’s procedure | Evidence remains insufficient to identify one record |
Neither method should require the guest to announce personal information to a line of people. Ask whether results can be limited to the current location and a reasonable time range, and which details are visible to a cashier. If the vendor offers a search by personal information, decide whether your staff actually need it for this task.
Work through two similar orders
Hypothetical example: A guest says they submitted a kiosk order around 12:10 and cannot find their order number. They remember ordering a chicken sandwich with no onion and a lemonade. In a simulated order list, the cashier finds these two records:
- Order 418: submitted at 12:09; chicken sandwich with no onion and lemonade; payment shown as completed; order shown as in preparation.
- Order 419: submitted at 12:11; chicken sandwich with extra onion and lemonade; payment shown as completed; order shown as in preparation.
The time and main items alone fit both records. The no-onion modification distinguishes order 418 from order 419, so the cashier can treat 418 as the likely match after confirming that detail with the guest. The cashier should read the status as displayed and follow the restaurant’s procedure for checking progress. The manager owns any further exception the cashier is not authorized to resolve.
Now change one fact in the simulation: suppose both sandwiches have no onion. The time, item, drink and modification no longer distinguish the records. The expected result is no confirmed match, not a guess based on which order was a minute earlier. The cashier asks for another detail already associated with the order, such as an order number if the guest can retrieve it. If no distinguishing evidence is available, the cashier asks the manager to use the manual recovery procedure.
Also simulate a conflicting payment status. If the likely order is shown as unpaid, the cashier should not describe it as paid just because the guest recalls completing payment. The manager should investigate using the restaurant’s approved process before anyone changes the order or discusses a payment resolution. A status label needs a clear meaning and, where available, a way to see whether it has updated.
This example is about matching evidence, not a promise that a particular product displays or searches every field. Before choosing software, write down which details would distinguish your most common similar orders. A pizza shop might need size and toppings; a coffee shop may need drink size and milk choice. If your menu produces many identical orders, plan for a manager decision when the visible evidence does not identify one record.
Run a pass/fail vendor test before purchase
Ask the vendor to demonstrate your workflow using a sandbox or other isolated practice environment with fictional records. Confirm beforehand that the exercise cannot trigger a real payment, guest message or courier dispatch. Do not use a real guest’s information. If the vendor cannot provide a safe practice setup, review screens and a documented walkthrough instead, and keep the unanswered items open in your buying decision.
Have a cashier operate the workflow while the manager observes. Give the cashier the guest’s statements, not the answers from the order list. Record the result, the screen used and who takes the next action.
- Number search: Provide a fictional order number and a matching item detail. Pass if the cashier can find the intended record, confirm the detail and identify its displayed status. Fail if the record cannot be found or the result does not provide enough evidence to confirm it.
- Time search: Provide an approximate time and two similar fictional orders with one different modification. Pass if the cashier can narrow the candidates and explain why one matches. Fail if the workflow requires a guess or unnecessary guest data.
- Ambiguous exception: Make both orders identical on the details the guest remembers. Pass if the cashier recognizes that neither is confirmed and escalates. Fail if the workflow or staff procedure treats proximity in time as proof.
- Manual recovery: Use a fictional missing-number case with no distinguishing detail. Pass if the manager can follow a documented recovery path without changing the wrong record. Fail if responsibility or the next step is unclear.
- Status conflict: Show a fictional record whose payment status conflicts with the guest’s account. Pass if staff can see the status and know whom to ask before acting. Fail if they must assume payment was completed.
Ask the vendor: “If a kiosk order does not appear in the cashier’s view, what should staff check first, who can help, and what information does support need?” Also ask what happens when a connection is interrupted and how the cashier can tell whether the list is current. Get the recovery steps in writing and decide who on each shift will use them.
A demonstration is not the same as a live service pilot. After the simulated checks, a limited live pilot can help you observe the normal workflow with staff following your established procedures. Agree on supervision, escalation and a fallback before starting; do not promise uninterrupted service or assume every exception will be caught.
Finally, review how the kiosk fits with your restaurant POS system and broader restaurant management software. Include any required hardware, installation, support and staff training in your quote comparison. For a wider cost decision, use the kiosk break-even guide.
Next, bring your completed worksheet to a Fleksa restaurant kiosk discussion. Ask for a demonstration of the lookup, status and recovery steps you require, and confirm feature availability for your setup.
Frequently asked questions
Is an order number enough to identify a kiosk order?
It is a useful starting point, but staff should also confirm an item or modification. If the number or details conflict, stop and investigate rather than acting on the first result.
What if the guest does not know the order number?
Search an approximate submission time if the system allows it, then compare order details. If more than one record fits, ask for another distinguishing detail or involve the manager.
Should cashiers search by phone number?
Only consider it if it serves a real need in your workflow. Ask what information the system stores and displays, and whether time and order details can resolve the request without collecting more guest data.
