Ask guests whether they understood the reward, what they expected to happen, and how much effort it took to use it. Then compare their answers with what staff observed: Was the guest eligible? Did the employee know the steps? Did the software behave as expected?
Collect feedback from people who redeemed successfully as well as those who tried and could not. A successful discount can still involve confusing instructions or an awkward wait. A failed attempt may expose a rule guests did not understand, a training gap, or a workflow worth testing with the vendor.
Ask short, neutral questions about understanding and effort
Keep the conversation optional and brief. A guest collecting takeout may have time for one question; a guest settling a dine-in check may not want another conversation at all. Staff can offer a short question after the attempt, then accept a refusal without pressing.
Use questions that let the guest describe the experience in their own words:
- Before you tried to use the reward, what did you expect it to cover?
- What, if anything, was unclear about using it?
- How easy or difficult was it to use the reward today?
- Was there a step where you had to stop and ask for help?
- What would have made the process clearer?
For an unsuccessful attempt, add: “What did you expect to happen when you tried?” Avoid asking “Was the app confusing?” before the guest has described the problem. That wording suggests both the cause and the answer. Similarly, “Everything worked fine, right?” makes it harder to report a problem.
Do not turn the questions into a defense of the program. If a guest expected a free item but the reward applied only to a discount, record that expectation. The immediate job is to understand the gap, not persuade the guest that the terms were clear.
For consistency, staff can use a simple effort scale: easy, neither easy nor difficult, or difficult. Keep a short optional note alongside it. A rating alone will not tell you whether the guest struggled to find the reward, understand its conditions, or explain it at the counter.
Ask about the actual attempt rather than overall satisfaction. “Would you recommend us?” may be useful elsewhere, but it does not explain why a reward took several steps to apply. The separate question of whether a reward is affordable belongs in a reward-cost review.
Include successful and failed attempts without collecting personal details
Choose a short review period and ask staff to note attempts across different shifts and ordering situations. Include guests who used a reward without help, those who needed assistance, and those who abandoned or failed the attempt. If you only ask people who finish redemption, you miss the friction that prevented others from finishing.
There is a practical limit: staff may never see someone give up while ordering alone. Ask your vendor what information, if any, the system can show about attempted and completed redemptions. Do not assume an abandoned attempt is recorded. The feedback you collect at the counter is still useful, but it is not a complete count of every guest experience.
Use a shared worksheet with a random entry number rather than a guest name. Record the shift, ordering situation, reward type, outcome, short guest comment, and staff observation. Avoid names, phone numbers, email addresses, payment details and screenshots containing account information. A note such as “expected the reward to cover the drink; cashier explained food-only condition” is more useful than a record of the guest's identity.
Keep feedback separate from a marketing contact list. A guest answering a question has not necessarily agreed to receive promotional messages. If the restaurant needs to follow up on a specific problem, use its normal approved process rather than placing contact information in the feedback worksheet.
Brief staff before starting: ask when the guest is not holding up the line, record the answer without correcting it, and note whether help was offered. Review entries together at the end of the period. A few comments can reveal a problem worth investigating, but they should not be treated as a representative survey of all guests.
Sort feedback into causes before choosing a fix
Group each note by the most likely issue, while allowing an “unknown” category. Eligibility covers the reward's conditions and how they were communicated. Staff training covers the steps an employee should take. Software behavior covers what appeared or happened during the attempt. A single experience can involve more than one category.
The following hypothetical worksheet shows how an operator might move from a guest comment to an action. It is an example for discussion, not a set of customer results.
| Guest or staff observation | Likely category | Next action |
|---|---|---|
| Guest expected a drink to be included; the reward was limited to food. | Eligibility or wording | Compare the displayed offer with the actual condition; clarify the wording if needed. |
| Guest had the right reward, but the employee did not know where to begin. | Staff training | Make a short shift guide and practice the steps with employees. |
| Staff followed the stated steps, but the expected discount did not appear. | Software behavior or unknown | Document the conditions and ask the vendor to reproduce the attempt safely. |
| Guest succeeded after asking which reward could be used. | Understanding or visibility | Check whether the available reward and its conditions are easy to find. |
The table separates what someone observed from the cause you suspect. That distinction matters. A cashier may say “the reward didn't work,” while the guest may have expected a reward that was not available for that order. Conversely, an employee's unfamiliarity with the screen does not prove the underlying software is faulty.
For a training issue, write down the intended steps in plain language and include what staff should say if the reward does not apply. For an eligibility issue, compare the offer guests see with the conditions employees are expected to enforce. If those do not match, fix the explanation before considering a broader rule change.
Ask the vendor how staff can distinguish a reward a guest has earned from one the guest can actually redeem on the current order. A points balance or a reward equivalent does not, by itself, establish that a particular reward is available or eligible for that purchase.
Set a decision boundary and test the uncertain cases
Consider a separate hypothetical review of 12 observed reward attempts. Eight guests complete redemption and four do not. Of the eight completions, three guests say they needed help understanding a condition. Of the four failures, staff identify two as ineligible under the stated terms; for the other two, staff believe the conditions were met but cannot explain the result.
The first decision is not to expand eligibility. Five attempts involved either confusion about a condition or an ineligible order, but that does not establish that the condition itself is wrong. Compare the offer wording with those five accounts. If it accurately describes the condition but guests still expect something else, rewrite the explanation and coach staff on how to present it. If the written offer promises something different from the rule staff apply, resolve that mismatch first.
The two unexplained failures cross a different boundary: staff believe the reward should have applied, yet the outcome is uncertain. Ask the vendor to check the exact reward, order contents, channel, timing and steps taken before changing the rule. Do not count those two as software defects until the cause is established. Do not use this small, selected set to estimate the failure rate for every guest.
Agree on an acceptance check before testing. For example: given an eligible reward and an order that meets its stated conditions, the expected result is that the reward is available and the correct adjustment appears before the order is finalized. Also check an ineligible order: the expected result is that the reward is not applied and staff can explain the condition. Ask what a guest sees in each case and whether that message can be adjusted.
Run practice checks in a vendor-approved test environment or simulation. A simulation must not create a real card payment, guest message or courier dispatch. Confirm the setup with the vendor first; if those effects cannot be prevented, do not use the practice scenario as described. A live service pilot is different: it involves actual guests and transactions, so plan staff supervision and normal operating procedures separately rather than calling it a simulation.
Document the steps, expected result and observed result without guest identifiers. If the simulation matches expectations, investigate staff guidance and guest-facing wording. If it does not, give the vendor enough nonpersonal detail to investigate, then repeat the check after a correction. Leave the eligibility rule alone until you know which problem you are trying to solve.
Before choosing or changing a system, compare how the redemption workflow fits the rest of your restaurant management process. Fleksa's marketing software describes loyalty points for eligible orders, alongside marketing tools; ask which orders qualify and how guests and staff see redemption conditions in your setup. To take the next step, bring your questions and acceptance checks to discuss requirements with Fleksa and compare the workflow with your current product needs.
Frequently asked questions
Should staff ask every guest who uses a reward?
Not necessarily. Choose a manageable review period and include different shifts, successful redemptions and visible failed attempts. Ask briefly when service allows, and let guests decline.
What if a guest says redemption was difficult but cannot explain why?
Record the difficulty without assigning a cause. Note the ordering situation and whether staff helped, then look for similar reports. Use a safe simulation to investigate a repeatable step rather than guessing.
When should a restaurant change its reward rules?
Consider a rule change after separating unclear wording, staff execution and software behavior from the rule itself. If the conditions are working as intended but no longer fit the experience you want to offer, review the proposed change and its operational consequences before introducing it.
