Choose loyalty reward expiry rules that guests can understand and your team can explain. For many restaurants, a fixed deadline from the date a reward is earned is easier to communicate than an inactivity rule. No expiry can be simpler for guests, while an inactivity rule may suit a program that rewards an ongoing relationship. The right choice depends on how often guests visit, whether reminders can reach them, and how much exception handling your team can absorb.
Start with the reward a guest can actually redeem, not just the points they have collected. Then decide when that reward expires, what notice guests receive, and who can make an exception. Check the legal requirements and your software's capabilities before publishing the policy.
Compare three ways to handle expiry
No expiry removes the deadline from the guest's decision. It can fit a neighborhood restaurant with occasional visitors or a team that wants fewer disputes about dates. The tradeoff is that rewards remain available for longer, so the restaurant needs a way to track outstanding rewards and plan for redemptions. Ask whether the vendor can report older balances and whether any other program changes could affect them.
Fixed expiry gives each earned reward a deadline, such as 90 days after it becomes redeemable. Guests have a date to act on, and staff can point to a consistent rule. The downside is that a guest who visits infrequently may miss the window, particularly if they never see a reminder. A longer period can reduce that friction, but it also keeps rewards outstanding longer.
Inactivity-based expiry ties the deadline to a period without a qualifying action. It may be a reasonable fit when regular engagement matters more than the age of an individual reward. But the definition of activity becomes critical. Does a purchase count only when completed? Does opening an email count? Does activity extend all rewards or only a points balance? If staff cannot answer those questions quickly, guests are likely to struggle too.
Do not assume points and rewards have the same deadline. A guest might have points that are not yet enough to claim anything, a reward already available to redeem, or both. State which balance the rule covers and what happens when a guest crosses the threshold for a redeemable reward.
A decision worksheet with hypothetical inputs
Assume a small cafe has many guests who return about once a month, but some visit only every few months. The owner wants a clear deadline, can review a short exception list each week, and is willing to keep rewards available long enough for several normal return visits. The team has not yet verified which rules or reminder schedules its software supports.
| Rule | Guest effect | Operating concern | Decision for this cafe |
|---|---|---|---|
| No expiry | No reward deadline to remember | Track older outstanding rewards | Simple alternative if deadlines cause too much friction |
| Fixed: 120 days after earning | About four months to use a reward | Explain the date and handle missed reminders | First choice to investigate |
| Inactivity: 120 days | Qualifying activity may extend eligibility | Define activity and explain resets | Less suitable unless the system makes the rule clear |
The table recommends a fixed 120-day period because it gives this cafe's monthly guests several chances to return while keeping the deadline easy to explain. It is not a universal benchmark. If most guests visit only twice a year, the same deadline could feel unnecessarily short. If the software cannot show the deadline or support the planned reminders, the cafe should reconsider the rule rather than rely on staff to fill the gap.
For the financial side, list the number of redeemable rewards outstanding and the expected cost when each is used. A points balance may have a reward equivalent for planning, but that does not mean the guest can redeem it yet. The guide to calculating reward cost can help you work through the economics separately from the expiry decision.
Trace one reward from earning to expiration
Continue with the hypothetical cafe. A guest earns a redeemable reward on January 1. The policy says it expires 120 days after earning, on May 1. For clarity, the cafe defines the last usable moment as the end of May 1 in the restaurant's local time. Before launch, it needs to confirm that its system calculates and displays that same deadline.
The guest should see the reward and its deadline when it becomes available, in whatever customer view or confirmation the restaurant actually uses. The message should say what the reward buys, any meaningful restrictions, and the last day to use it. For example: “Your free drip coffee reward is available through May 1.” If a purchase is required or particular sizes are excluded, say so alongside the offer rather than hiding the condition in a separate policy.
The cafe would like to send a reminder 30 days before expiry and another seven days before expiry. Those are planned reminders, not an assumption that every loyalty tool can schedule them. Ask whether the vendor can trigger messages from the individual reward's deadline, suppress a reminder after redemption, and avoid sending the same notice twice. Check which channels are available and whether the restaurant has permission to use each channel for that purpose.
If the guest redeems on April 15, the reward should no longer appear available and the remaining expiry reminder should be suppressed. If the guest does not redeem, the reward expires at the stated cutoff. The guest-facing view and staff view should then agree on its status. A mismatch can turn a simple deadline into an awkward conversation at the counter.
Contact information and marketing permission are separate things. Having a phone number or email address does not automatically mean the restaurant may send every kind of campaign. Ask your adviser how to handle the messages you plan to send, and ask the vendor how it records preferences and applies send controls. Fleksa describes email and SMS campaigns and segmentation in its restaurant marketing automation tools; confirm the specific reminder workflow in a demonstration.
A reminder is helpful, but it should not be the only place the deadline exists. A guest who opts out of marketing or changes contact details still needs a reasonable way to find the terms and check the reward. Decide what staff will say when a guest claims a notice never arrived.
Set the support rule and measure its workload
Write a short reinstatement policy before the first reward expires. For example, the hypothetical cafe might allow a manager to restore one expired reward when the guest reports a problem within seven days of the deadline. The manager records the reason and the new deadline. That is an operating choice for this example, not a legal safe harbor or a recommendation to deny every later request.
Decide who can approve an exception, whether a restored reward has a new expiry date, and how the guest learns it has been restored. Also decide what happens if the system cannot reinstate the original reward: can an authorized employee issue an equivalent offer, and can it be tracked separately? Do not promise restoration until you know what staff can actually do.
Give the front-of-house team a short response: check the guest's account and deadline, explain the published rule, and refer eligible requests to the person authorized to decide. Avoid asking an employee to guess whether a reminder was delivered or whether an exception has already been used.
For a separate hypothetical workload estimate, suppose the cafe expects 20 expiry questions in a month. It estimates four minutes for each question and another six minutes for each of five requests needing manager review. That is 80 minutes plus 30 minutes, or 110 staff minutes. At an assumed internal labor cost of $18 per hour, the estimated variable staff cost is $33 for the month.
That estimate includes ordinary question handling and the five exception reviews. It excludes fixed software and setup costs, message charges, the cost of any restored rewards, and unusual escalations. It is a planning estimate, not a quote or a prediction. Compare those omitted costs separately before choosing a rule.
Review reports at a regular interval. Useful measures include rewards earned, redeemed, expired and restored; the number of expiry questions; and the reasons for exceptions. Ask whether the system can separate those events and export the underlying data. A high expired count alone does not tell you whether guests understood the deadline, received a reminder, or simply chose not to redeem.
Also check whether reports show the status of individual redeemable rewards rather than only aggregate points. Fleksa's loyalty documentation and marketing loyalty FAQ are useful starting points; ask to see the specific expiry and reporting controls your policy needs.
Verify the rules before rollout
Expiry rules can be affected by local law and by how a program is structured. A free promotional reward, a purchased gift card, and stored value should not be treated as interchangeable just because all three appear in a marketing system. Ask a qualified legal adviser to review your terms, deadline, notices, reinstatement approach, and any planned changes to existing rewards. Ask a qualified tax adviser about the treatment of your particular program if needed.
Then put your intended policy in writing and use it as a vendor checklist. Ask:
- Can we set expiry from the date a reward becomes redeemable, from account inactivity, or not at all? Can points and redeemable rewards have different rules?
- What is the exact cutoff time and time zone? Where can guests and employees see the deadline?
- Which actions count as activity, and does activity extend one reward or an entire balance?
- Can a manager restore a reward or issue a tracked replacement? Is there an audit trail?
- Can reminders be scheduled by reward deadline, stopped after redemption, and sent according to the guest's contact preferences?
- What happens to existing rewards if we change the policy? Can we export reward status and exception history?
Ask for a written quote that separates fixed software or setup charges, variable messaging charges, and any charges for exceptional support or changes. Those are operating costs; they are separate from the cost of providing redeemed rewards. Confirm what is included rather than assuming a quoted message rate represents the whole program cost.
Before putting the policy in front of guests, run a simulated check in a training or sandbox environment. Walk through earning a reward, viewing its deadline, simulating a reminder, redeeming it, and requesting an exception. Use test data and ensure the exercise cannot send a real guest message or take a real payment. Record where the displayed terms, staff instructions, and system behavior differ.
If you then choose a live service pilot, limit it to a clearly identified group and use the actual published terms and normal guest permissions. Staff should know it is live, monitor questions, and have a way to pause or correct the process. A simulation checks the workflow safely; a live pilot shows how the policy operates with real guests.
Next, write down your preferred expiry period, reminder schedule, and exception rule. Compare those requirements with Fleksa and request a demonstration of the relevant workflow before committing to a policy.
Frequently asked questions
Should restaurant loyalty rewards expire?
They do not necessarily need to. A deadline may help define when a reward can be used, while no expiry can reduce guest confusion. Consider visit frequency, outstanding reward costs, support capacity, and applicable legal requirements.
Should points and earned rewards expire together?
Not necessarily. Points that have not reached a redemption threshold are different from a reward a guest can use now. Decide the rule for each, explain it clearly, and confirm the software can apply it.
What should staff do when a guest misses a deadline?
Check the reward status and published terms, then follow the restaurant's exception policy. Give an authorized person responsibility for any restoration or replacement and record the outcome.
