Loyalty program gamification: games with real prizes, budget and control
Resources · Guide
Gamification in a loyalty program uses games, missions and badges to drive a behavior: one more visit, top-up or purchase. It has two layers: the one that shows the game (the wheel, the moment, the channel) and the one that decides what the game can pay, which budget it comes from and where the prize is recorded.
- WheelPrize per slice
- Scratch cardThe shortest gesture
- Mystery boxThe box that opens
The member
- BudgetCapped per game
- LedgerEvery prize recorded
- IdempotencyNo double prizes
- PurchaseEarns a play
- Before the animationPrize decided and recorded
- On screenSees the prize
Customer impact · SKY Plus case
SKY Plus, SKY Airline’s program, runs on Qurable: points, missions, three tiers and partners on a single platform.
SKY Plus is one of our cases: we also run programs in retail, fuel, restaurants and banking.
- 1.7M+Active membersIn the SKY Plus program
- 70+Integrated partnersHotels, dining and airport services
- 210KFlights a monthProcessed by the platform
- 50KDaily transactionsWith program partners
Key takeaways
- A game with prizes has two layers: the one that shows it and the one that decides what it can pay and records it.
- The prize is decided before the animation, against a capped budget, and it's recorded.
- With Qurable, a game is set up and integrated into your app or website in less than a week.
Two layers
The game is shown on top. The prize is paid underneath.
The top layer (which game, for whom, when and through which channel) is usually well handled by the engagement tool. The layer underneath (how much the prize is worth, which budget it comes from and where it's recorded) is often custom development.
| A counter and custom code | A game on a ledger | |
|---|---|---|
| Where the prize lives | A profile attribute that goes from 3 to 4 and a webhook that notifies another system | A ledger entry with the rule that granted it, its cost and its expiry |
| If the notice repeats | The counter moves twice and nobody notices until reconciliation | Each play carries an idempotency key: the second call hands out nothing |
| Budget | An alert when it's exceeded | A capped budget per game: when it runs out, prizes stop |
| Reversal | Still to build | Every prize can be reversed, with its entry |
| Liability | Calculated at month end | In real time, for finance |
| A new game | Another development project | Configured in the console; integrating it into your app or website takes less than a week |
The pieces
What a game with real prizes has to solve.
Four groups of pieces, from the screen to the record. They also work as a checklist to evaluate any vendor.
Seven ways to show the result
Wheel, scratch card, slot machine, mystery box, doors, cards and memory. The mechanic only changes the staging: the prize is decided before.
Missions and badges
Multi-step challenges with visible progress, a reward on completion and a cap per member.
Stamps, trivia and contests
Stamp cards, questions with prizes and contests with their own rules, on the same engine.
Odds per prize
Every prize has its own odds, and members never see the exact odds.
A capped budget
Every game draws from a budget; when it runs out, the game stops handing out prizes.
Play caps and audience
Who plays, how many times and on which dates, with an automatic cap on plays per game.
Every prize, recorded
Points, coupons, cashback or badges go into a double-entry ledger with the rule that granted them.
Idempotency key
If the app or a webhook retries, the play isn't applied twice.
Reversal and liability
Every prize can be reversed with its entry, and finance sees the liability in real time.
Plays and prize rate
Every published game shows its plays, prize rate, remaining attempts and budget.
A/B tests
Versions of the same game or promotion side by side, in the builder.
Control group
Incrementality with a control group is designed with each program: it's the difference between “it went up” and “it went up versus those who didn't play”.
What goes wrong
When the prize has nowhere to be recorded.
The animation is almost never the problem. The problems come with the money the game hands out.
| Problem | What it takes |
|---|---|
| A retry hands out the same prize twice | An idempotency key per play: the second call does nothing. |
| The game keeps paying after the budget runs out | A hard cap per game that stops prizes, not an email alert. |
| Nobody knows how much the program owes in prizes | Every prize recorded in a ledger and the liability in real time. |
| A prize given by mistake can't be undone | A full or partial reversal, with its entry. |
| Results are compared with last month | A control group that doesn't get the game, designed from the start. |
| Every new game is a development project | Games configured from the console, with an SDK you integrate once. |
By industry
Where it pays off and with which mechanic.
It pays off where customers buy often, the extra visit leaves margin and the prize can be a product instead of a discount.
Fuel
A wheel after the fill-up
Fill-up challenges and store combos. The best prize is a high-margin store product, not a discount on fuel.
Restaurants and delivery
A scratch card after the order
Missions by time slot to move off-peak hours, with product prizes.
Retail
Missions by category
To push the category that isn't moving, with tiers for the best customers.
Banks and fintech
Activation missions
With a real-value prize, the entry, the cap and the reversal are requirements for the risk team.
Casinos and entertainment
Prize economics
Customers already think in odds and caps: the conversation starts with the game's budget.
How to evaluate
Four questions any vendor should answer in a demo.
All four can be shown with the product on screen. If the answer is a document, it isn't an answer.
Where is the prize that just came out recorded?
An entry says when, under which rule, against which budget, with which expiry and how much liability it added. A counter going from 3 to 4 isn't an entry.
What happens if the webhook fires twice?
The right answer is that the second call does nothing, because the play carries an idempotency key.
What's the game's cap, and what happens when it's reached?
A game with real prizes needs a capped budget that stops handing out prizes. If the cap is an alert, it isn't a cap.
Can you show me the control group?
It's the difference between “orders went up” and “orders went up versus those who didn't play”.
With Qurable
The prize is decided before the animation and it's recorded.
At Qurable, the prize of every play is decided against its odds and a capped budget, and it's recorded in the ledger before the member sees it. Setting up a game and integrating it into your app or website takes less than a week, and Qurable integrates with your CRM and engagement tool: it doesn't replace them.
Games and missions
Seven mechanics, missions, badges, stamps and contests, configured from the console.
See Engagement & LoyaltyPrizes with accounting
A double-entry ledger with reversals, idempotency and real-time liability.
See the points ledgerIn your app and website
An SDK you integrate once; every new game ships without development and with your brand.
See the platformAt the moment of purchase
The play is earned with the purchase at the till, in ecommerce or in the app.
See loyalty at POS and checkout
Questions
What teams ask before launching a game with prizes.
For marketing, loyalty and finance teams considering gamification for their program.
It's using games, missions, badges and contests to drive a customer behavior: one more visit, top-up or purchase. It works when the prize is well chosen, comes from a capped budget and is recorded, so the program knows what it costs.
At Qurable: wheel, scratch card, slot machine, mystery box, doors, cards and memory, plus missions, badges, stamp cards, trivia, contests and referrals. Each game has prizes with their own odds, a cap on plays and a budget.
With a capped budget per game, which stops handing out prizes when it runs out, and with every prize recorded in a ledger with the rule that granted it and its cost. Finance sees the liability in real time and every prize can be reversed.
At Qurable it doesn't: every play carries an idempotency key, so if the app or a webhook retries, the second call doesn't hand out another prize.
With Qurable, setting up a game in the console and integrating it into your app or website takes less than a week. The following games need no development: they're configured.
No. Qurable integrates with your CRM and engagement tool through APIs and webhooks. Those tools can decide when to show the game; Qurable decides what it can pay and records it.
Every game shows its plays, prize rate and budget, and the builder supports A/B tests. To know how much extra it sold, you need a control group that doesn't get the game: at Qurable it's designed with each program.
Last reviewed
Further reading
Keep reading before you launch.
The pages that show each piece in detail.
- ModulePoints program
Games, missions, tiers and redemption.
- ModulePoints ledger
Entries, reversals and the liability of every prize.
- ResourcePoints and rewards engine
Build your own or use an API-first platform.
- ResourcePoint value
What it costs the company and what the member perceives.
- ResourcePoints liability
How it's calculated and controlled.
Want to see a game with real prizes in your app?
In a 45-minute demo we build a game with your budget and answer the four questions with the product on screen.