Choose a single-use code when the offer is meant to be redeemed once and the software can enforce that limit everywhere you accept it. Choose a reusable code when repeat use is part of the offer or when a shared code is easier to operate and the extra exposure fits your budget.
The important detail is what “single use” actually means. A code may be usable once in total, once per guest, or once in each ordering channel. Those are different policies. Before sending an offer, write down the intended limit, decide how staff should handle exceptions, and check that the system can show what happened.
Model one offer under both code policies
For the following hypothetical example, a restaurant wants to offer $5 off one eligible takeout order to each of 100 invited guests. The offer runs from Monday through Sunday. It can be presented through direct online ordering or at the counter. The owner wants no more than one discount per invited guest across those two channels.
A suitable single-use design would give each invited guest a different code, with each code accepted once in total across both channels. That design works for the stated goal only if redemption in either channel updates the same limit before another attempt is accepted. It also assumes guests do not receive or use each other’s codes. Ask the vendor how codes are issued, whether they can be shared, and whether a guest-level limit is available if you need one.
A reusable design might give everyone the same code, such as TAKEOUT5. It is easier to print on a sign or include in a broad message. Unless another limit is enforced, however, the same guest could use it on multiple eligible orders. That can be appropriate for a repeat-visit promotion, but it does not meet this example’s one-discount-per-invited-guest goal on its own.
Use the worksheet below to compare the intended behavior with what a vendor can demonstrate. “Pass” describes the restaurant’s acceptance criteria, not a claim about any particular product.
| Decision | Single-use policy | Reusable policy | Pass for this offer |
|---|---|---|---|
| Who receives it? | One distinct code per invited guest | One shared code | Distribution matches the intended audience |
| How often? | Once per issued code across both channels | Repeated use unless another limit applies | A second use of the same entitlement is rejected |
| Where? | Online or at the counter, with a shared limit | Online or at the counter, subject to configured rules | A use in either channel counts against the same limit |
| When? | Monday through Sunday | Monday through Sunday | The displayed deadline and system cutoff agree |
The table separates a code’s identity from the guest’s identity. A unique code can prevent that code from being used twice, but it does not necessarily stop someone from using two different codes. If one offer per person is essential, ask how the system identifies a person, what happens when contact details change, and what information staff can see without exposing more guest data than they need.
Trace redemption across two channels
Continue the same hypothetical offer with a guest who has one unique code. First, the guest enters it on an eligible online order. The expected result is one $5 discount and a record that the code has been redeemed. Next, the guest presents the same code at the counter. The expected result is a clear rejection, not a second discount.
Reverse the sequence as well: start with the counter, then try online. A system that checks only its own channel could pass the first sequence by accident and fail the second. Also ask what happens when two attempts are submitted close together. If the limit updates slowly, both may appear valid before either record is visible.
Run these as simulations in a vendor-provided test environment or with noncharging test transactions. Practice must not create a real payment, send a guest message, or dispatch a courier. If a safe test mode is unavailable, ask the vendor to demonstrate the sequence with test data before deciding whether to run a controlled live pilot.
Use observable criteria for each simulation:
- Pass: The first eligible attempt receives exactly one $5 discount; the repeat attempt is rejected in the other channel.
- Pass: Staff can see enough information to explain that the code was already used, without seeing unnecessary guest details.
- Fail: Both channels accept the code, the discount appears twice, or staff cannot determine the outcome.
- Fail: A rejected attempt looks like a completed order, or an accepted discount has no usable record.
Include a canceled order and a corrected order in the demonstration. Ask whether canceling restores the code, who can restore it, and whether that action is recorded. Decide your own policy before launch: for example, a canceled order might justify a replacement code, but a completed order followed by a change of mind might not. Staff need a consistent answer either way.
When comparing a restaurant POS system with your online ordering setup, ask whether both channels enforce the same redemption record. A shared screen or matching code name alone does not prove a shared limit.
Make expiry, overrides, and reporting clear
Guest-facing terms should say what the discount applies to, where it can be used, the deadline, and whether the code can be used more than once. For the example, the message could say: “$5 off one eligible takeout order. Use your code online or at the counter by Sunday.” Add the actual cutoff time and time zone when you configure the campaign.
Check that the checkout message matches the offer terms. An expired code should produce an understandable response rather than a generic error that sends the guest to the counter for an explanation. Simulate one attempt just before the cutoff and another just after it. Both should follow the published deadline in each channel.
Staff also need a small exception policy. Choose who may approve an override, which reasons are acceptable, and whether staff should apply a manual discount or issue a replacement code. Give the team a short script: acknowledge the problem, check the available record, and explain the next step. Do not ask a cashier to guess whether a code was legitimately used.
A useful report should let the manager distinguish issued codes, successful discounts, rejected repeat attempts, and manual exceptions. Ask whether it shows the channel, time, discount amount, and staff action where relevant. Check whether records can be exported for reconciliation and how long they remain available. A report that counts only successful sales may not explain why guests complained about rejected codes.
Review the offer message alongside your restaurant marketing automation requirements. Ask how recipients are selected and how sending is controlled. Having a guest’s contact details is separate from having permission to send a marketing message.
Compare exposure and operating cost before launch
For the hypothetical offer, a unique code with a shared cross-channel limit is the better fit because the owner wants one discount per invited guest. If that limit cannot be demonstrated, either change the offer terms to permit repeated use, restrict the offer to a channel that can enforce the rule, or postpone it. Do not rely on staff memory to enforce a digital limit across orders.
Compare operational costs using a separate hypothetical quote worksheet. Suppose a vendor quotes $40 in fixed campaign setup, $10 in variable code and messaging charges for the planned send, and an estimated $15 for staff time handling exceptions. The estimated operating total is $65: $40 + $10 + $15. Those figures are fictional, not Fleksa prices. The estimate includes the stated fixed, variable, and exception costs; it excludes the discounts themselves, payment processing, other software charges, and any later campaign changes.
If 60 eligible orders each receive the intended $5 discount, the face value of discounts is $300. That is separate from the $65 operating estimate and is not the same as sales or profit. Unexpected repeat redemptions would increase the discount total, while staff investigations could increase exception costs. Ask for a written quote and use your own expected order volume and labor assumptions. Where contract or tax treatment matters, consult a qualified adviser.
For Fleksa, check the current plans and pricing; pricing details were checked in November 2026. Confirm which charges and features apply to your setup rather than assuming a plan includes a particular code workflow.
Before committing, write your acceptance criteria on one page, request the safe cross-channel demonstration, and compare the result with the staff process you can support. Compare your requirements with Fleksa and confirm current availability before choosing a workflow.
Frequently asked questions
Does a single-use code guarantee one offer per guest?
No. It may limit each code rather than each person. Ask how codes are distributed, whether they can be shared, and whether the system can enforce a guest-level limit across your chosen channels.
When is a reusable restaurant code a good choice?
It fits an offer intended for repeated use or broad distribution when the restaurant accepts the potential discount cost. Make any order, date, and channel limits clear to guests and staff.
What should staff do when a guest says a code failed?
Check the expiry and available redemption record, then follow the restaurant’s exception policy. A designated approver can decide whether to issue a replacement or apply an authorized adjustment and record the reason.
