In almost every meeting this year, someone showed me a spinning wheel. Wheels, scratch cards, mystery boxes: games are back in loyalty programs, and for good reason. They give customers a reason to come back between purchases.
But when I ask who keeps track of what the game hands out, the conversation changes. The animation is solved. What often isn’t solved is the prize.
Two layers, and only one comes solved
The engagement tool decides which game to show, to whom, when and through which channel. The market handles that well, and there are valuable findings there: sometimes what drives redemptions isn’t the game but the moment it appears.
The other layer decides how much the prize is worth, which budget it comes from, when it expires, whether it was already delivered and whether it can be reversed. The more the prize looks like money, the more that layer matters. And it’s the one people talk about least.
The interest in games is real: 27% of Gen Z describe loyalty programs as “not fun,” according to Euromonitor International. Games help. The question is what happens with what they hand out.
Where is the prize that just came out recorded?
A profile attribute that goes from 3 to 4 isn’t an entry. An entry says when the prize was delivered, under which rule, against which budget, with which expiry and how much liability it added to the program.
If the answer is “a counter goes up and a webhook notifies another system,” the game’s accounting lives somewhere else. Someone will have to build it.
What happens if the webhook fires twice?
It happens more than people think: an app retry, a dropped connection, a system that didn’t confirm in time. The right answer is that the second call does nothing, because the play carries an idempotency key.
Any other answer means a member can collect the same prize twice and nobody will notice until reconciliation.
What’s the game’s cap, and what happens when it’s reached?
A game with real prizes needs a capped budget that actually stops handing out prizes. If the cap is an email alert, it isn’t a cap: it’s a notice that you already went over.
Can you show me the control group?
It’s the question almost nobody answers. “Orders went up” isn’t the same as “orders went up versus those who didn’t play.” Without a group that doesn’t get the game, you don’t know how much extra you sold or how much you gave away to people who would have bought anyway.
That’s why, when we set up a pilot, the control group is part of the proposal, not a methodological detail.
How we solve it at Qurable
At Qurable, the prize is decided before the animation. Every play is resolved against its odds and a capped budget, and the prize goes into a double-entry ledger with the rule that granted it, before the member sees it. Every play carries its idempotency key and every prize can be reversed.
The mechanic is the staging: wheel, scratch card, slot machine, mystery box, doors, cards or memory. Setting up a game and integrating it into an app or website takes less than a week. And we don’t replace your CRM or your engagement tool: we integrate with them. They can decide when to show the game; we decide what it can pay and record it.
What I like most about starting with a game is what it leaves installed: connected events, a capped budget and the ledger. The second program is no longer an integration, it’s configuration.
Before you launch your next game
- Where is every prize recorded?
- What happens if the notice repeats?
- What’s the cap, and what happens when it’s reached?
- Where is the control group?
If your vendor answers all four with the product on screen, the game is ready to hand out real prizes. If not, you know what’s left to build.
Frequently asked questions
Four things: where every prize is recorded, what happens if a prize notice repeats, what the game's budget cap is and what happens when it's reached, and how results are measured against a control group.
Because every prize is a cost and, often, a debt to the customer. A ledger records when it was delivered, under which rule, against which budget and with which expiry, allows reversing it and shows the liability in real time.
It's the guarantee that the same play is applied only once. If the app or a webhook retries, the second call doesn't hand out another prize.
Setting up a game in the console and integrating it into an app or website takes less than a week. The following games are configured, without development.
