A guest can use a promotion at a kiosk only if the ordering setup supports that offer and its restrictions. Before buying, ask the vendor to demonstrate the exact promotion you want to run: how the guest enters it, which items qualify, what happens before payment, and how an employee can help if it fails.
The decision is whether that workflow is reliable enough for your service. A code box alone does not answer it. The guest needs to understand the result, the total must be clear before payment, and staff need a workable way to review an order without holding up the line.
Set the service requirements first
Start with one promotion you expect to use. Write down its eligible items, discount, dates, redemption limit, and any exclusions. Decide whether it can be combined with other offers. If the promotion applies only at certain locations or times, put that in the rules too.
Then assign an owner. A shift lead might approve the promotion setup and handle exceptions, while a cashier helps guests during service. A manager should be responsible for checking that the offer is removed or disabled when it ends. The right people depend on your staffing, but each task needs a name.
Service conditions matter. A kiosk beside a staffed counter gives a guest somewhere obvious to ask for help. In a small dining room with one employee covering both the register and pickup, frequent voucher failures could interrupt both jobs. A restaurant that rarely runs promotions may prefer a simple staff-assisted process to paying for a more elaborate setup.
Set a practical acceptance standard before demonstrations. For example: the guest can see the discount and revised total before payment; an ineligible item does not receive it; and a rejected code gives the guest a clear next step. If a cashier cannot review the order until after payment, decide whether that limitation is acceptable rather than assuming staff can intervene earlier.
Trace one voucher through an order
The following example is hypothetical. A restaurant offers $3 off one eligible sandwich. Drinks are excluded, and the offer cannot be combined with another promotion. The guest orders an $11 sandwich and a $4 drink. For this illustration, tax, payment processing, and other fees are excluded; there are no fixed or exception costs in the displayed order total.
The shift lead owns the offer rules. Before launch, that person asks the vendor to show how the sandwich is identified as eligible and the drink as ineligible. The team also needs to know what happens if a menu item is renamed or a qualifying item is removed.
The guest selects the sandwich and drink, then enters the voucher at the point provided in the ordering flow. The kiosk should show the result before asking the guest to pay:
- Sandwich: $11
- Drink: $4
- Subtotal: $15
- Eligible sandwich discount: −$3
- Total for this illustration: $12
The drink stays at $4. The discount is applied once to the sandwich, not to the whole order or to both items. If the guest removes the sandwich, the expected result is that the $3 discount disappears and the drink returns to a $4 total. Ask the vendor to demonstrate both states, including any message the guest sees.
The cashier owns the immediate response if the guest needs help. Agree on whether the employee can inspect the current order at the kiosk, find it on a register, or must rebuild it at the counter. Those are different workflows; availability should be demonstrated for your setup. The restaurant POS system is worth including in that discussion because the handoff matters as much as the screen where the code is entered.
Finally, the guest should be able to review the order before deciding whether to pay. Fleksa's restaurant kiosk page describes browsing, customization, and order review; ask specifically how your proposed voucher and restrictions would work in that flow.
Compare approaches by the work they create
Use the table to compare approaches, not to assume that a particular vendor offers them. The right-hand column identifies the questions that can change your cost or decision. Request a written quote for the complete setup you would actually use.
| Approach | Guest experience | Staff effort | Cost and vendor questions |
|---|---|---|---|
| Guest enters a voucher at the kiosk | Guest can complete the offer without approaching the counter if it works. | Staff set up offers and handle rejected codes. | Is voucher entry supported for these rules? Are setup, licensing, hardware, and changes included in the quote? |
| Staff assists at the kiosk before payment | Guest waits for an employee but may keep the current order. | Employee leaves other work to review or correct the order. | Can staff see and act on an unpaid order? Is a staff login or extra device needed? |
| Guest takes the order to the counter | Guest has a clear fallback but may need to repeat selections. | Cashier reviews the offer and may rebuild the order. | Can an unpaid kiosk order be retrieved? What happens to the original session? |
| Promotion is available only at the counter | Guest cannot redeem it independently at the kiosk. | Cashier handles every promotional order. | Does the simpler setup reduce quoted costs enough to justify the added counter work? |
Compare operational quote totals on the same basis: hardware, installation, recurring software charges, payment processing, and the expected work to configure or change offers. Ask about support and any charges for exceptions. A quoted processing fee alone is not the all-in cost of operating a kiosk. For a broader cost comparison, use the self-order kiosk break-even guide.
Under the hypothetical offer above, an operator who expects guests to use the code often and has limited counter coverage might prefer kiosk redemption if the demonstration meets the acceptance standard. If the vendor cannot show the item restriction or a workable prepayment handoff, the safer choice is to keep that offer at the counter until a suitable workflow is available. That is an operational choice, not a claim that one approach always costs less.
Run a rejection and recovery check
Before selection, ask for a simulated demonstration using test data. Do not use a real card, send a guest message, or dispatch a courier. Agree on who plays the guest, who acts as the cashier, and who records the result. The cashier should not receive advance instructions beyond the normal staff procedure; that makes the handoff more useful to observe.
For the hypothetical promotion, enter a rejected code with only the $4 drink in the basket. The expected behavior is no discount, a $4 total before payment, and a message that tells the guest what to do next. Then try the valid code with the sandwich and drink and check the $12 total. Also try removing the sandwich after the discount appears. The offer should no longer reduce the drink price.
Record the screen shown at each step, the displayed amounts, and whether the employee can review the transaction before payment. Ask when that review becomes possible: while the guest is still at the kiosk, only after a staff login, or only when the order has been recreated at the counter. Do not assume that a staff member can retrieve or change an unpaid kiosk order.
Mark the check as a pass only if the restriction is applied correctly, the price is visible before payment, and the documented staff recovery works at the agreed point. It fails if the drink is discounted, the guest cannot see the revised total before payment, or staff cannot provide the promised help. A clear rejection with a usable counter fallback can pass if that fallback was part of your acceptance standard.
If the workflow fails, choose a manual fallback before running the promotion. For example, direct guests to the cashier, have the cashier verify eligibility, and enter a new counter order under the restaurant's normal approval process. Ask how to end or abandon the original kiosk session so it does not create confusion. Tell staff what they may approve and when to call the shift lead.
A simulation checks the proposed steps without serving a guest. If you later run a live service pilot, brief the team, set a limited period, and monitor real exceptions under your normal operating procedures. A live pilot is not needed to make the initial simulated check.
Choose the workflow you can support
Keep a short decision record: the promotion rules, the demonstrated guest flow, the point where staff can review an order, the fallback, and the written quote. Include who will update the offer when the menu changes and who will tell staff when it expires.
Before committing, compare that record with your current counter process. Review the kiosk documentation, then ask Fleksa to demonstrate the applicable voucher and staff-recovery capabilities for your specific promotion and setup.
Frequently asked questions
Can every restaurant voucher be used at a kiosk?
No. Support depends on the ordering setup and the offer's rules. Ask the vendor to demonstrate your actual eligibility restrictions and the price shown before payment.
What should staff do when a voucher is rejected?
Follow a defined recovery path: review the offer and order at the point your setup allows, or direct the guest to a cashier who can verify eligibility and handle a counter order.
Should a voucher test use a real payment?
No. Use a simulated order and test data to check the discount, rejection message, and staff handoff. Keep any later live service pilot separate from that simulation.
