Let members choose an early reward or save for a larger one when both options have a clear purpose and your system can show the tradeoff accurately. The early reward gives guests a reason to use their points sooner. The larger reward gives them a reason to keep earning. Neither should surprise the guest at checkout or leave your team guessing about the cost.
The owner or manager should make the tier decision with input from whoever manages the menu and the ordering system. Before buying loyalty software, work out what each reward costs, what points remain after redemption, and what happens if a guest changes their mind.
Decide what each reward is meant to do
An early reward can make the program feel useful to a guest who visits occasionally. A small side or drink may be more appealing than waiting for a reward they cannot imagine reaching. But frequent early redemptions can create food and staff costs without leaving much room for a larger reward.
A higher tier may suit regulars who want a more substantial menu item. The risk is that guests see a distant target and never use their points. If the only visible option is the larger reward, a guest who has already earned a smaller one may miss a reason to return.
Start by choosing two items you can reliably offer. Ask your kitchen lead about ingredient cost, preparation time, substitutions, and whether either item is regularly unavailable. A reward with a low ingredient cost can still slow service if it requires special handling.
Then decide what happens to points. Does an early redemption deduct only the points spent, leaving the rest available? Can a member redeem the early reward more than once? Can two rewards be used on the same order? These rules affect both the guest's choice and the restaurant's potential cost. Put them in writing before configuring the program.
Keep the offer understandable: show the points needed, the item the guest receives, and any meaningful restrictions. A dollar-value equivalent can help with internal comparison, but it is not itself a reward unless guests can actually redeem that value.
Use a two-tier cost worksheet
The following figures are hypothetical. They are a way to compare choices, not a description of Fleksa features or pricing. Assume guests earn one point per dollar of eligible purchases, the early reward is a side at 50 points, and the larger reward is an entrée at 100 points. Redeeming deducts the listed points. For this example, assume a member may redeem the early reward twice, including on one order.
The table compares food costs at the point of redemption. It includes the estimated ingredients for each reward. It excludes fixed software costs, payment fees, extra labor, packaging, and exception costs such as remakes or substitutions. Those excluded costs belong in the operating quote or a separate estimate before you approve the program.
| Guest choice | Points spent | Rewards received | Estimated food cost |
|---|---|---|---|
| Redeem early | 50 | One side | $2 |
| Save for the larger tier | 100 | One entrée | $5 |
| Use the early tier twice | 100 | Two sides | $4 |
The comparison is not simply $2 versus $5. At 100 points, the restaurant might provide one entrée for $5 or two sides for $4 under the assumed rules. The guest may value the entrée more, while another guest prefers two sides across separate visits. Your actual menu costs and redemption rules may reverse that comparison.
A member at 50 points can take the side now, leaving zero points, or keep the balance and earn 50 more points for the entrée. Under the earning assumption, that means $50 more in eligible purchases. That amount is sales, not profit or a payment fee; it does not tell you what the restaurant earns after the cost of those purchases.
Estimate reward food cost using current portions and ingredient prices, then revisit it when the menu changes. For a fuller method, see the guide to calculating loyalty reward costs. If you expect frequent substitutions, add an exception-cost estimate rather than assuming every redemption uses the standard item.
Compare guest choice and outstanding rewards
Now use the same hypothetical tiers to think about points already held by members. Suppose 70 members each have 100 points. If every member redeems one entrée, the estimated food cost is 70 × $5, or $350. If every member instead redeems two sides under the assumed rules, the estimate is 70 × $4, or $280. These are alternative outcomes, not amounts to add together.
Those figures are planning estimates for food fulfillment, not a calculation of the accounting liability or a prediction that every member will redeem. Actual obligations depend on the program terms and applicable accounting treatment. Ask a qualified adviser how to treat outstanding points and rewards in your books.
The worksheet still reveals a useful operational exposure: a balance report showing 7,000 points does not, by itself, tell the kitchen which items guests will choose. Check whether your vendor can report points outstanding, rewards available, and redemptions by tier. Ask whether you can export the information for your own analysis.
Under these assumptions, offering both tiers is a reasonable starting choice: the early option is accessible at half the points, and two early rewards cost less in ingredients than one larger reward at the same total points. That recommendation depends on guests being allowed to choose and on the excluded costs not changing the comparison. If preparing two sides creates substantial extra labor or packaging cost, recalculate before launch.
Assign the menu manager to maintain the food-cost estimate and the program owner to review point balances and redemptions. Set a review date after launch. If the early reward is heavily used but the larger one is rarely selected, ask whether guests understand the choice and whether the larger item is attractive enough to justify waiting.
Test both choices before you buy
Ask each vendor for a demonstration using a sandbox, demo account, or another isolated setup. This is a simulation, not a live service pilot. Do not use a real card payment, send a guest message, or dispatch a courier. Give the vendor your written tier rules and ask them to show the guest view and the staff view.
- At 50 points: The expected result is that the side is available and the entrée is not yet redeemable. The guest should be able to keep the points rather than being forced to redeem. The program owner records pass or fail.
- At 100 points: The expected result is that the guest can see both the side and the entrée, with the points required for each. If the guest selects the side, the simulated balance should fall to 50; if they select the entrée instead, it should fall to zero. Run these as separate simulated choices from the same starting balance.
- Repeated early reward: If your intended rules allow it, check whether two sides can be selected and whether the balance falls from 100 to zero. If your intended rules prohibit two on one order, test that restriction instead. Do not accept a workaround that contradicts the terms you plan to publish.
- Exception and recovery: Simulate the side becoming unavailable after a guest selects it. Ask the vendor to show what the guest sees and whether staff can remove the reward and restore the correct points without creating an order or sending a message. The shift manager should be able to explain who is authorized to make the correction.
- Support: Ask how to report a disputed balance, what transaction details support needs, and who can correct it. Record the response, expected follow-up, and any limits on staff access.
Fail the demonstration if the displayed choices, deductions, or restrictions differ from your written rules. A feature that looks close may still create a counter dispute if guests see a reward they cannot use. Ask for the gap and any agreed correction in writing before signing.
Also check where points can be earned and redeemed. A program may need to fit orders taken through different channels, but you should not assume every channel is eligible. Ask how a cashier identifies the member, what happens when an order is canceled, and whether points are restored after a reward is removed. Compare those answers with the workflow in your restaurant POS system and restaurant management software.
If the demonstration passes, plan a separate, limited live service pilot with staff who know the rules. Give them a contact for balance problems and review exceptions after each shift. A live pilot involves real orders and guests, so use your normal payment and communication controls; do not treat it as a simulation or assume it will be error-free.
Make the next decision
Write your two reward items, point deductions, repeat-redemption rule, and estimated costs on one page. Add the expected results above and ask vendors to demonstrate them. Then compare your marketing requirements with Fleksa and confirm whether the loyalty setup you need is available for your ordering channels.
Frequently asked questions
Should the larger reward always cost less per point?
No. Compare what guests can actually redeem and what each option costs to fulfill. A larger reward may be more attractive even if its food cost per point is higher, provided that cost fits your plan.
Can a guest redeem an early reward and keep saving?
That depends on your program rules and software. If you want points left after an early redemption to remain available, specify the deduction and test the resulting balance before launch.
Are outstanding points the same as a restaurant's accounting liability?
No. Points and estimated food costs help with operational planning, but they do not establish the accounting treatment. Ask a qualified adviser how to account for your program.
