Why Loyalty Programs Fail: Breakage, Inflation, Trust
Loyalty programs fail for a structural reason that has very little to do with creative, budget, or app design: in most of them, the issuer's economics improve when the member never redeems. Points are issued as a liability on the balance sheet, and an unclaimed liability eventually becomes revenue. Once that is true, every downstream decision — expiry windows, tier resets, blackout dates, the shape of the redemption catalogue — is made by an organization that quietly benefits from friction. Members work this out. The program does not fail because engagement was low; it fails because the promise was never structured in a way that made keeping it attractive to the issuer.
That is the honest starting point for anyone evaluating a rewards layer, and it applies to every vendor in the category, ourselves included. Below are the five failure modes we see repeatedly, and what a program has to do structurally — not tonally — to escape them.
Failure one: breakage as a business model
Breakage is the industry term for rewards that are issued and never claimed. In accounting terms it is the release of a liability. In practice it is the quiet centre of most loyalty P&Ls.
The problem is not that breakage exists. Some breakage is unavoidable in any system where people accumulate small balances and lose interest. The problem is when breakage becomes the plan. Once a program is financially modelled on non-redemption, the operator has an incentive to make redemption slightly harder every year, and the incentive never points the other way. Nobody writes that down. It emerges from the model.
The tell is easy to spot from the outside. Ask an operator what their redemption rate is and whether they want it higher. A program built to be redeemed treats a rising redemption rate as proof the thing works. A program built on breakage treats it as margin compression.
Failure two: inflation with no anchor
A point is worth whatever the issuer says it is worth this quarter. There is no external reference, so the exchange rate can move at will, and it moves in one direction. Award budgets get generous during a growth push. Redemption costs get repriced when finance looks at the liability. The member's balance is unchanged in units and smaller in value.
Currencies with no anchor devalue. That is not a moral failing of loyalty managers; it is what happens to any unit of account whose issuer controls both supply and price and faces no obligation to defend either. The member absorbs the difference and, unlike a currency holder, has no market to exit into.
This is why the anchoring question matters more than the earn rate. A reward that references something with value determined outside the program cannot be silently repriced by the program. We have written separately about what real world value means as a design constraint, and the constraint is exactly this: an external reference removes the issuer's ability to change what a balance is worth by editing a config value.
Failure three: balances that die at the edge of one product
Most reward balances are trapped inside the surface that issued them. Leave the app, churn from the brand, stop playing the game, and the balance is gone — not spent, just stranded.
Operators often treat this as a feature, because a stranded balance is a switching cost. It is a weak one. A balance that only has value if the member stays is functionally a hostage arrangement, and members price it accordingly: they discount the reward because they do not believe they will be around to use it. The lock-in the operator thinks they bought is paid for with a lower perceived value on every point issued.
It also caps the program's reach. A siloed balance cannot be earned in one place and spent in another, which means the program can never be worth more than the traffic of the single product that runs it. Portability across surfaces is what turns a reward from a retention gimmick into something a member treats as an asset. That is the premise behind a shared reward layer spanning multiple products rather than a per-app points scheme.
Failure four: redemption friction that is engineered, not accidental
Redemption is where programs reveal what they actually are. The patterns are familiar: minimum thresholds set just above the typical balance, catalogues stocked with items priced at implausible point values, seasonal availability, multi-step claim flows with an identity check bolted onto the end, and support queues that are cheaper to abandon than to complete.
Each of these is defensible individually. Thresholds reduce fulfilment cost. Identity checks reduce fraud. Together, and tuned in the direction the P&L prefers, they form a suppression system. A useful internal test: measure the drop-off at every step between "eligible to redeem" and "received the thing," then ask which of those steps you would keep if breakage were worth nothing to you. Most operators find at least one step that only survives because it does not work.
Failure five: the trust deficit that follows
The four failures above compound into a fifth, and the fifth is the one that actually kills programs. Members stop believing the balance means anything. Once that belief is gone, awarding more points does not move behaviour, because the currency has no credibility to spend.
This is why re-launching a failed program rarely works. The new tiers and new artwork are addressed to an audience that has already learned the lesson. Trust in a reward system is earned in redemptions, not impressions, and it is rebuilt at roughly the speed it was lost.
What a program has to do differently
Escaping these failure modes is not a matter of better intentions. It requires three structural properties, each of which costs the issuer something real.
- Anchor the reward to something outside the program. If the issuer can reprice the unit unilaterally, it will eventually. An external reference is what makes the value defensible.
- Make balances portable across surfaces. A reward that survives the member leaving one product is worth more per unit than one that does not, which is the trade the issuer is actually making.
- Make redemption honest and instrument it. Publish the path. Measure completion. Treat a rising redemption rate as the success metric rather than the cost line.
Those three properties are what distinguish rewards infrastructure from a points feature, and they are the reason a growing number of teams treat this as a build-versus-buy decision rather than a marketing project. We cover the category boundaries in our overview of rewards as a service, and the integration mechanics in the piece on what a rewards API has to expose.
Where this leaves Flashy
The obvious rejoinder is that we sell into this category, so of course we describe the failure modes in a way that flatters our design. Fair. So it is worth stating the cost of our own position.
Flashy Gold is designed as a reward redeemable for Real World Value — real world assets, experiences, and services. Anchoring to real-world value is a materially harder promise to keep than issuing points. Points cost the issuer a database write. An anchored reward implies obligations that persist whether or not the quarter went well, and it removes the lever that makes conventional programs profitable, which is the ability to quietly reprice. There is no version of this where the anchoring is the easy part.
That is the point. A reward layer that cannot be silently devalued is only worth building if the difficulty is accepted up front rather than discovered later, and the honest way to evaluate any vendor here — including us — is to ask what stage each part of the system is actually at.
Ours, concretely: the issuance and balance layer is live, and the Flashy Gold API already powers live web apps. Redemption is at waitlist stage, and we say so on the record in the redemption waitlist announcement rather than describing it as shipped. A category built on the argument that programs mislead members about redemption does not get to be vague about its own.
What to ask before you commit
If you are evaluating a rewards layer for a consumer app, a game, or a brand network, the diligence questions that separate infrastructure from theatre are unglamorous. What determines the value of one unit, and who can change it? What happens to a balance when the member stops using the issuing product? What is the measured completion rate from eligibility to fulfilment? Which parts of the redemption path are live today and which are announced? Is the answer to all of the above verifiable by someone outside the company?
Teams working through those questions with us usually start at the Flashy Gold product overview and then talk to us about integration. The programs worth building are the ones where the answers hold up when a member checks them.