Send an unused-reward reminder to an enrolled member only when they have an actual reward they can redeem, the reward is still valid, the reminder falls within your chosen timing window, and you have permission to contact them on the selected channel. Exclude members who have redeemed the reward, unsubscribed, or cannot be confidently matched to it.
That audience is narrower than a general win-back list. A guest who has not ordered lately may have no reward at all. A frequent guest may have an unused reward and benefit from a reminder. The decision starts with the reward, not the date of the last visit.
Start with a redeemable reward and permission
Define what counts as an unused reward before building the audience. A redeemable reward is an available benefit the guest can actually claim under your program rules. A points balance that is merely equivalent to a future reward does not qualify if the guest still needs to earn points, select a reward, or meet another requirement first.
For each member, your selection needs enough information to answer four questions:
- Is the member enrolled, and can the reward be matched to that member?
- Has the reward been issued or otherwise made available for redemption?
- Is it unused and valid at the planned send time?
- Does the member have marketing permission for the chosen email or SMS channel?
Contact information alone is not permission to market. A phone number collected for an order, for example, does not by itself answer whether the guest agreed to receive promotional texts. If permission is missing, withdrawn, or unclear, leave that contact out of the marketing audience until the record is resolved.
Also check whether the reward has conditions that affect the message. A reward limited to a particular location, ordering method, or item should not be described as usable everywhere. If the system cannot put the relevant condition in the message, use accurate general wording and direct the guest to the full reward details.
Fleksa's marketing software page describes email and SMS campaigns, segmentation, and loyalty points for eligible orders. Ask whether your proposed setup can select actual redeemable rewards, check permission by channel, and exclude used rewards at send time. Do not assume that every order channel earns points or that having campaign tools automatically settles consent requirements.
Set the reminder window around the expiry rule
A reminder is useful when a guest has enough time to act and the message describes the deadline accurately. Start with the reward's stated expiration date and time, including its time zone. Then choose a window that gives guests a reasonable chance to visit or order.
For example, an operator might choose one reminder when a reward has three through seven calendar days left. Under that rule, a reward with seven days left qualifies; one with eight days left waits. A reward with two days left is outside that particular window, even though it remains valid. The operator could choose a separate last-chance message, but should define that as a different rule rather than quietly adding those members to this audience.
Decide how to handle rewards without an expiry date. They do not belong in an expiry-based audience unless you create a separate rule, such as a reminder a set time after the reward becomes available. Avoid implying that a reward expires soon when it does not.
Be equally clear about the number of messages. A member may have more than one unused reward, or may enter the timing window on several daily audience runs. Choose whether to send one message per member or one per reward, and set a limit so a daily refresh does not produce repeated reminders unintentionally. If rewards have different deadlines, decide which deadline the message will show.
Before buying, ask the vendor how it calculates the window: by calendar date or exact hours, in which time zone, and using which expiry field. Ask whether the audience can refresh before a scheduled send and whether the message can show the correct deadline and restrictions. If the answer requires manual exports, account for the staff time and the risk that a list becomes stale.
Use a sample audience to draw the boundary
The following is a hypothetical worksheet, not guest data or a description of any product's behavior. Assume the audience is checked at 9 a.m. local time on June 10. Rewards expire at the end of their listed date. The rule is one email per member for an unused, currently redeemable reward expiring three through seven calendar days after June 10, with valid email marketing permission. Include both boundary dates: June 13 and June 17.
The table shows how that rule treats different records. It does not say whether a guest is likely to return or spend more.
| Member | Reward record | Email permission | Decision |
|---|---|---|---|
| A | Unused and redeemable; expires June 13 | Granted | Include: three-day boundary |
| B | Unused and redeemable; expires June 17 | Granted | Include: seven-day boundary |
| C | Unused and redeemable; expires June 18 | Granted | Exclude: too early for this window |
| D | Redeemed; original expiry June 15 | Granted | Exclude: reward already used |
| E | Unused and redeemable; expires June 15 | Withdrawn | Exclude: no email permission |
| F | Points could earn a reward, but none is redeemable; expiry June 15 | Granted | Exclude: no redeemable reward |
Member C can be reconsidered on a later audience run if the reward remains unused and permission remains valid. Member E should not be moved to SMS just because an email unsubscribe exists; check permission separately for that channel. Member F might qualify for a different points message, but should not receive a claim that an unused reward is waiting.
Write down your own boundary cases before choosing software: a reward expiring today, a reward with no expiration, a member with two rewards, and a record with an unknown status. For unknown or conflicting records, a practical default is to exclude the member until the data is corrected. That protects the guest experience as well as the accuracy of your campaign.
Check suppression before a live send
An audience that was correct when scheduled can be wrong by delivery time. A guest may redeem the reward, withdraw permission, or have a reward canceled after the list is built. Ask whether the system checks those changes again immediately before sending, and how quickly updates from each ordering or loyalty source appear.
Run a simulated acceptance check with fictional records and a non-delivering test mode. The simulation must not create a real payment, guest message, or courier dispatch. Use these checks with the vendor:
- Redeem after selection. Mark a fictional reward as redeemed after the initial audience is built. The expected result is that its reminder is suppressed before the simulated send.
- Unsubscribe after selection. Withdraw the fictional member's email permission. The expected result is exclusion from the email send, even if the reward remains unused.
- Cross the timing boundary. Move a fictional expiry from inside the window to outside it. The expected result is exclusion under the stated rule.
- Check duplicates. Give one fictional member two qualifying rewards and run the selection twice. Compare the result with your chosen per-member or per-reward limit.
- Check the message. Preview the deadline, location or item restrictions, and reward wording against the fictional record. A correct audience still needs an accurate message.
Record the expected and actual simulated outcomes, including any update delays. If suppression only happens when an operator uploads a fresh list, decide who owns that step and how close to sending it must occur. Ask how to stop a scheduled campaign if a data problem appears.
A simulation is different from a live service pilot. Only after the simulated checks pass should you consider a small live campaign using genuine eligible members and normal permissions. Set a staff review point, check the send and redemption reports, and have a way to pause. A live pilot sends actual messages; it should not be used to discover whether basic unsubscribe or redemption suppression works.
For measurement, compare sent reminders with the relevant reward redemptions over a defined period, while recognizing that a redemption alone does not prove the message caused it. Check whether reporting and exports identify the reward and campaign without exposing more guest data than staff need. Your restaurant management workflow also matters: staff should know how to explain the reward and resolve a guest's question at the counter.
Ask for a written quote covering campaign tools, message charges, setup, and any ongoing work needed to keep reward data current. A processing fee or per-message rate alone is not the all-in operating cost. Review Fleksa's plans for current pricing; the plans page was checked in November 2026. For the value of the reward itself, use the loyalty reward cost guide separately from the cost of sending reminders.
Bring your timing rule, sample records, and suppression expectations to a vendor conversation. Discuss your requirements with Fleksa and compare the workflow and current product fit before scheduling a live campaign.
Frequently asked questions
Should every member with points get a reminder?
No. Points that could eventually become a reward are different from a reward the guest can redeem now. Use a separate message and audience if you want to remind members about their points balance.
What if a reward has no expiration date?
Exclude it from an expiry-based reminder. If a reminder still makes sense, create a separate timing rule and avoid suggesting that the reward is about to expire.
What should happen if a guest redeems after the audience is selected?
The reminder should be suppressed before sending. Ask how the vendor refreshes reward status, how quickly redemption updates arrive, and what manual step is needed if an automatic recheck is unavailable.
