A reward change can make redemptions rise simply because more guests had more time to use the offer. To make a useful comparison, separate the old and new rewards, count the guests who could actually redeem each one, and give both groups the same observation window.
Then look beyond the rate. Check what each redemption costs, whether guests had a fair chance to see the offer, and whether the result supports the decision you need to make. A cleaner comparison is not proof that the reward alone caused the difference, but it is a better basis for deciding what to do next.
Start with the decision, not the total
Before pulling a report, name the person who will decide whether to keep, adjust, or remove the new reward. In a small restaurant, that may be the owner. In a group, a marketing manager might prepare the comparison while an operations leader approves the change.
Write down the decision in practical terms: keep the new reward for another month, change its requirements, or investigate why eligible guests are not using it. Also agree on when the review will happen. A reward introduced yesterday needs more observation time than one that has been available for several weeks.
Define a redemption before counting it. A useful starting measure is the number of eligible guests who redeemed the specific reward at least once, divided by the number of eligible guests in that comparison group. This is a guest redemption rate, not a count of all reward transactions. A guest who redeems twice counts once in the numerator.
Eligibility needs a concrete rule. For a points reward, a guest may have to reach a threshold and still have enough points available. A points balance that resembles the value of a reward is not necessarily a reward the guest can redeem. Check the actual requirements, expiration rules, and participating order channels.
Use a separate measure for the number of reward redemptions if repeat use matters. Keep that transaction count out of the guest-rate numerator. Otherwise, a few frequent guests can make a reward look popular across the whole eligible group.
Build comparable groups and time windows
Record both enrollment date and exposure date for each guest. Enrollment date is when the guest joined the loyalty program. Exposure date is when the guest first had a documented opportunity to see the particular reward, such as when it appeared in a place they could access or when a permitted message was sent. A sent message is not proof that the guest read it.
For each reward, define an index date: the first date the guest was both eligible and exposed to that reward. Start the observation window on that date. If a guest saw the reward before earning enough points, the window starts when eligibility begins. If the guest was eligible before the offer appeared, it starts at exposure.
Compare guests with similar enrollment histories where practical. A guest who joined last week may behave differently from a regular who has collected points for a year. For example, compare guests enrolled within a similar period who became eligible for the old reward with those who became eligible for the new one. Keep the reward version attached to every record, especially if both versions were available during a transition.
Choose a window that fits the restaurant's visit pattern, such as 30 days after the index date. Include only guests who have completed that full window by the report cutoff. If guests lose eligibility during the window, record when and why; a nominal 30-day window is not the same as 30 days with a usable reward. Report short eligibility periods separately rather than quietly treating them as full opportunities.
A simple calendar-period comparison is quicker: count results in the month before and the month after the change. It can help spot a sharp operational problem, but it is weak for judging the reward itself when group size, exposure, or time available differs. A guest-based, fixed-window comparison takes more work and is usually more useful for the buying decision.
Neither approach removes every difference. Holidays, store hours, marketing campaigns, menu changes, and guest mix can affect results. If the new reward was launched alongside a major promotion, note that before attributing a change to the reward. If reliable eligibility or exposure dates are unavailable, say what the report can measure and avoid presenting it as a matched comparison.
Use a reward-change worksheet
The following figures are hypothetical. Assume both groups enrolled in a comparable period, had the same 30-day observation window, and remained eligible throughout it. Each guest had one documented opportunity to see the applicable reward. The new reward was available to more guests, so raw totals alone would favor it.
| Worksheet item | Old reward | New reward |
|---|---|---|
| Eligible and exposed guests with a complete window | 80 | 120 |
| Guests who redeemed at least once | 24 | 30 |
| Guest redemption rate | 24 ÷ 80 = 30% | 30 ÷ 120 = 25% |
| Total redemptions, including repeat use | 28 | 35 |
| Estimated variable reward cost per redemption | $2 | $3 |
| Estimated variable reward cost | 28 × $2 = $56 | 35 × $3 = $105 |
The new reward has six more redeeming guests and seven more redemption transactions. Yet its guest redemption rate is five percentage points lower. The comparison does not show that the new reward caused the decline; it shows that the larger total is not enough to establish better participation.
The cost rows estimate variable reward cost only. They include the assumed cost for each redemption, including repeat redemptions. They exclude fixed program or software costs and exception costs such as manual corrections or replacement rewards. They also exclude any sales associated with the visits. These figures are not all-in operating costs or profit estimates.
Under these assumptions, the owner should investigate rather than immediately declare the new reward a success. The expected next result is a checked report showing whether the lower rate persists in another complete window and whether the higher cost per redemption fits the restaurant's goal. Assign the loyalty manager to verify eligibility and exposure records, then bring the comparison to the owner for a decision. If the restaurant has one manager, put that person's name and review date on the worksheet.
Also record the reward terms beside the worksheet: points required, what the guest can receive, where it can be used, and any expiry. If the new reward requires substantially more points or is unavailable on a popular channel, that context belongs next to the rate, not buried in a separate report.
Check the numbers before acting
Reconcile the guest count to the underlying records. Remove duplicate profiles according to a consistent rule, and check whether canceled or reversed redemptions appear in the transaction total. Keep a small exception log with the guest record, reward version, reason for adjustment, and person who made it. Do not silently delete inconvenient rows.
Ask whether the same guest can appear in both groups. If so, define the rule in advance. For a straightforward comparison, you might assign each guest to the first reward version for which they met the index-date rule, then report later exposure separately. This reduces overlap in the main table, but it also means the result describes that selected group rather than every possible redemption.
Check the operational outcome alongside the rate. If the reward is frequently redeemed but staff have to override it at checkout, the offer may need a process fix. If the rate is low, review whether guests can find the reward and understand its requirements before changing the value again.
For a fuller cost discussion, use the loyalty reward cost guide. If reports combine loyalty activity with sales, distinguish the value of sales from reward costs and payment processing fees. They answer different questions.
Test reporting before you buy
Bring a small fictional dataset to a vendor demonstration. Include enrollment dates, old and new reward versions, eligibility dates, exposure dates, a repeat redemption, and one reversed transaction. Set a report cutoff and ask the vendor to show only guests with a complete 30-day window. This is a simulation: do not use a real card payment, send a guest message, or dispatch a courier.
Use these acceptance checks:
- Pass: The proposed workflow separates reward versions and identifies eligible, exposed guests with complete windows. Fail: It can show only total redemptions without a usable denominator.
- Pass: A repeat redemption is visible in the transaction count but does not add another guest to the guest-rate numerator. Fail: The vendor cannot explain how its count handles repeat use.
- Pass: The reversed transaction is identifiable and the vendor can explain whether it is excluded or adjusted. Fail: The exception cannot be traced or reconciled.
- Pass: The team can export the needed records or use a documented manual worksheet, with an assigned person checking totals. Fail: Neither the report nor an accessible export supports the calculation.
For manual recovery, ask the vendor to walk through a fictional missing exposure date. The manager should flag that guest as incomplete, exclude the record from the main eligible-and-exposed denominator until it is resolved, and keep the reason in the exception log. Ask support: “Where would we find the original exposure record, and how would we correct the report if it cannot be recovered?”
A simulation checks the proposed workflow, not real service conditions. If the demonstration passes, arrange a separate live pilot with actual staff and agreed controls. Review real records after a complete observation window; do not assume the simulated result guarantees the live one.
Fleksa's restaurant marketing automation page describes segmentation, campaigns, and loyalty points for eligible orders. Ask how the reporting and export workflow would support your particular comparison, and which order channels earn points. Access to contact details is separate from permission to market to a guest. Also ask how loyalty records relate to your restaurant POS system and whether the workflow fits your wider restaurant management software.
Next, take your worksheet and fictional dataset to a vendor conversation. Compare your marketing requirements with Fleksa and confirm feature availability for your setup.
Frequently asked questions
Should I compare total redemptions or the redemption rate?
Use both for different purposes. Total redemptions show workload and help estimate variable reward cost. The guest redemption rate shows the share of eligible, exposed guests who redeemed at least once during the defined window.
What if the old and new rewards ran for different lengths of time?
Give each eligible, exposed guest the same observation window and include only completed windows in the main comparison. If that leaves too few records, wait for more time or label the result as preliminary.
Can a higher redemption rate prove the new reward works better?
No. A higher rate is useful evidence, but promotions, seasons, eligibility rules, and guest mix can also affect it. Review those differences before deciding whether to keep or change the offer.
