Start with an order number when the kiosk can give guests a readable copy and staff can match it to one order. Keep a staffed recovery path for guests who cannot find it. A name can help staff talk to a guest, but it is a weak sole identifier when two people give the same one. A different token, such as a scannable code, may work if guests can retrieve it and staff have a practical alternative when it will not scan.
The right choice depends on what the guest receives, what the employee can see, and how the system handles exceptions. Ask the vendor to demonstrate the complete match, not just the screen where an identifier appears. This decision is about identifying the correct order; signs and counter layout are separate pickup decisions.
Decide what the guest will present
For every option, write down the input, where it comes from, and what the pickup employee checks against it. An identifier only helps if it connects the guest to the right order in a view staff can actually use.
- Order number: A number assigned to an order may appear on a screen or receipt. The guest reads or shows it; staff match it against the order record. Ask whether the number is unique among active orders and whether staff can tell apart orders from different days.
- Customer name: The guest enters or gives a name, and staff look for that name on an order. It is easy to remember, but spelling differences, nicknames, and duplicate names can make a match uncertain.
- Another token: A code or other identifier may be presented or scanned. Ask how it reaches the guest, what equipment staff need to read it, and whether it identifies one order without showing unrelated orders.
Do not assume that a guest has a phone, wants to give a name, or can read a small number from across a counter. A printed or on-screen identifier may also be lost before pickup. Ask how long an identifier remains available and what happens if a guest closes the screen or declines a receipt.
A restaurant kiosk can let guests browse, customize, and review an order. Those steps do not by themselves establish how pickup identification works. Have the vendor show the handoff using the same devices and staff views you would expect to use in your restaurant.
Compare duplicate-name outcomes
The following worksheet is hypothetical. Assume two guests each enter the name Alex and place separate active orders: order 42 contains a veggie wrap, and order 57 contains a chicken bowl. Assume both orders are ready at roughly the same time. These numbers and behaviors are for comparison, not claims about Fleksa or any other system.
| Method | Guest presents | Staff check | Decision point |
|---|---|---|---|
| Name only | “Alex” | Two active orders share the name | Do not hand off until another detail distinguishes the orders |
| Order number | 42 | One active order matches 42 | Hand off after checking the order is ready and the number is within the active-order scope |
| Scannable token | Token for order 42 | Staff scan and see the matching order | Use only if the scan reliably opens the intended order and a fallback exists |
The table shows the checks needed, not a guarantee that any system provides them. With name-only matching, a careful employee sees two Alex orders and asks a neutral follow-up, such as which item the guest ordered. That adds a step, but it avoids choosing the first matching name. If the employee cannot distinguish the orders confidently, the employee should pause and involve the shift lead rather than guess.
Under the second outcome, the guest presents 42 and the staff view shows one active matching order. On these assumptions, the number is the better primary identifier because it distinguishes the two orders without asking the guest to announce a name. If the number is not unique in the relevant staff view, or guests frequently cannot retrieve it, that result changes: the number alone has not passed the decision test.
A token could be just as useful if it points to one order and works with the equipment at pickup. It adds a dependency, though: the guest must have a readable token and the reader must work. Compare that dependency with a short number staff can read manually. Do not choose a token solely because it looks more sophisticated.
Also consider what the employee must say aloud or display. A staff screen should help identify the order without requiring the employee to show a guest a list of other people’s orders. Ask the vendor which order details are visible during lookup and whether the employee can confirm a match without turning the staff screen toward the guest.
Demonstrate the failure path before buying
Make the vendor demonstration a simulation. Use fictional names and orders in a demo or test environment. No real payment, guest message, or courier dispatch should be triggered. The pickup employee operates the handoff while a shift lead watches the staff view and records whether each decision was clear.
- Create two simulated orders with the same name. Record each order’s items and identifier in the test notes. Ask the employee to find the right order using only the name first, then using the proposed primary identifier.
- Make an identifier unreadable. For a number, obscure a digit on a printed test slip. For a token, cover part of the code or otherwise simulate a scan failure. The pickup employee should recognize that the identifier cannot be used, rather than treating a partial match as confirmation.
- Remove the identifier entirely. Have the simulated guest say they lost the slip or closed the screen. Ask the employee to use the vendor’s proposed recovery process without displaying other guests’ orders.
- Simulate an order that is not ready. Present its correct identifier and confirm that staff can distinguish a match from permission to hand it off.
The shift lead owns the exception: if the employee cannot make a confident match, the lead stops the handoff and checks the order using the agreed staff process. The vendor should show what information is available for that check. If the only answer is to guess from a name or expose a list of other orders to the guest, the recovery path fails.
Keep the practice separate from a later live service pilot. If you proceed to a live pilot, train the team on the demonstrated procedure first, designate a shift lead for unresolved matches, and record problems using your normal operating process. A live pilot involves actual guests and orders; the simulation should not.
Set a pass-or-fail standard for the vendor
Before the demonstration, agree on the order scope being searched: for example, active pickup orders at one location. Ask whether identifiers can repeat within that scope and what happens when an old order has the same number. A visible number is not enough if staff cannot tell which record it refers to.
Use these acceptance criteria for the proposed workflow:
- Correct match: The employee identifies the intended simulated order among the duplicate-name orders without guessing. The vendor explains how the identifier is assigned and what makes it distinct in the agreed scope.
- Ready status: The employee can check that the matched order is ready before handoff, or the vendor clearly shows the separate staff step used to make that check.
- Limited disclosure: The guest does not need to see other orders or hear another guest’s details for staff to complete the match.
- Recovery: When the identifier is missing or unreadable, the employee follows a demonstrated fallback. If the fallback does not establish a confident match, the shift lead takes over and the order is not handed off on a guess.
- Usable handoff: The identifier can be obtained and presented in the ways the vendor proposes, and the employee can use the required equipment at the pickup point.
Pass the demonstration only if all five criteria are met in the simulated cases. Fail it if a duplicate name leads to an uncertain handoff, a failed scan has no workable recovery, or staff must reveal unrelated orders to proceed. Record the failure and ask the vendor to demonstrate a revised workflow; a verbal promise is not the same as a working handoff.
Include the wider setup in your buying questions. How does the identifier reach the staff view, and can the team use the same process when a device is unavailable? Does the proposed restaurant POS system show the details needed for the match? Review the Fleksa kiosk cart workflow for context, then ask the vendor to demonstrate the pickup-specific steps. For the wider equipment decision, use the kiosk break-even guide alongside written hardware, software, and installation quotes.
Next, take your duplicate-name and missing-identifier cases to a Fleksa kiosk discussion. Compare your requirements with the demonstrated workflow and confirm current support before choosing how guests will identify pickup orders.
Frequently asked questions
Is an order number always better than a customer name?
No. A number is useful when it uniquely identifies an active order and guests can retrieve it. If either condition fails, test a different identifier or a reliable recovery process. A name can still help conversation, but duplicate names need another check.
What should staff do when a guest loses the identifier?
Use the demonstrated recovery process to check order details without exposing other guests’ orders. If the employee cannot confirm the match, the shift lead should take over rather than guess.
Should a kiosk use a scannable pickup token?
Consider one if guests can easily retrieve it, staff can scan it at pickup, and the scan identifies the correct order. Test a non-scanning fallback as well; a token that cannot be read should not end the handoff process.
