There's a "loyalty program" line in your plan because a DTC brand you admire has one. Then you sit down to design yours and stall on the first question: what would a subscriber earn points for? Paying the invoice that renews itself?
That's the catch with a loyalty program for SaaS. The subscription already is the repeat purchase, so loyalty has to reward something else. This guide covers when loyalty beats referral, how to design points, tiers and expiry, and how to run loyalty and referral on one customer record. RefRef, which publishes this blog, is the worked example.
Our view, up front: most SaaS products should start with referral, and add loyalty when retention or feature adoption is the leak. A coffee card works because you buy a coffee most mornings and feel every stamp land. A subscription charges your card quietly once a month, and nobody has ever felt rewarded by an auto-renewal.
One plain note before the design sections. RefRef's loyalty programs pay a member's own events as account credit, a discount or a plan upgrade, and they don't run points balances, tiers, expiry or a member rewards page. So the points, tiers and expiry advice below is tool-neutral: it works whichever app you end up using.
What a loyalty program rewards in a SaaS product
Retail loyalty rewards purchases. SaaS loyalty rewards the actions that predict a customer will stay and grow, because the purchase takes care of itself. The usual candidates:
- Activation milestones: the first integration connected, the first report shared, the first project a teammate opens.
- A public review on a marketplace or review site.
- Switching to annual, which turns a monthly maybe into a yearly yes.
- Helping in the community: an accepted answer, a template other people copy.
- Inviting teammates into a seat-based plan.
- Referrals, which is where loyalty and referral programs meet.
Each of these is an event your backend already knows about. That's the useful part: you don't need a store loyalty app to watch for them, only a system that listens to your events and pays a reward when one lands. Each reward is set by an earn rule, the action that pays and how much. In RefRef, a loyalty program's rules evaluate every event of their type, with or without a referral, so a review earns its reward whether the reviewer arrived by invitation or by search.
Reward outcomes you'd pay for anyway: never clicks or logins. A review has a value you can argue about in a meeting; a login doesn't. Put "log in daily for points" in your program and you'll teach people to open a tab, collect, and close it again. Your engagement chart will look wonderful.
Your churn won't move.
Loyalty or referral: which lever first
Referral buys acquisition; loyalty buys retention and adoption. They solve different problems, so your first program depends on which problem is costing you more. Our rule, and it's judgment rather than a finding:
- Referral first if you need customers and already have happy ones. Cello, which sells referral software, reaches the same view in its guide to customer loyalty and recommends in-product referral for B2B SaaS.
- Loyalty first if churn or low feature adoption is the leak and you have an active base to reward.
- Both when reviews, upgrades and referrals come out of separate budgets and you want each paid on its own terms.
The evidence behind any rule like this is thin. In the Wharton write-up of a study by Schmitt, Skiera and Van den Bulte, referred customers a bank acquired in 2006 were worth 16% to 25% more than other customers. Their margin edge had faded to zero after about 1,000 days, but the retention edge held: they were about 18% more likely to stay. That's one bank, not a SaaS company. Harvard Business Review's much-quoted line that a new customer is "five to 25 times more expensive than retaining an existing one" cites no study at all, and no sourced study shows that loyalty points reduce SaaS churn.
Loyalty can't fix a product people leave for a reason.
If your customers quit halfway through a confusing setup, points are a bandage on an onboarding problem. Fix the onboarding first, then reward the people who get through it.
A worked example (hypothetical)
This model uses our numbers, not anyone's results, and every rate in it is an assumption. Swap in yours.
The company (hypothetical)
Paying customers 2,000 at $50 a month = $100,000 MRR
Monthly churn 3% = 60 customers lost a month
Referral program
Referral rate 1% of customers bring one paying customer a month = 20 new
Reward $50 account credit to each side = $100 per new customer
Cost 20 x $100 = $2,000 a month
Loyalty program
Rewards for annual switches, reviews, activation milestones
Members earning 600, about $5 of credit each a month
Cost 600 x $5 = $3,000 a month
Assumed churn change 3% to 2.5% = 50 lost instead of 60, so 10 kept a monthReferral wins this one clearly. It adds twice as many customers as loyalty keeps, for two-thirds of the money, and a kept customer pays exactly what a new one does. Per customer, referral costs $100 against loyalty's $300, a third as much.
Start with referral.
Now change the company. Same size, but churn runs twice as fast and few of your customers like the product enough to recommend it:
The flip (hypothetical)
Monthly churn 6% = 120 customers lost a month
Referral rate 0.25% = 5 new a month, $500 in credit
Loyalty, same budget $3,000 a month, aimed at onboarding milestones
Assumed churn change 6% to 5% = 100 lost instead of 120, so 20 kept a monthReferral is still cheaper per customer, but it tops out at a handful a month while the leak is many times bigger. Each kept customer now costs half what it did in the first model, and loyalty is the lever that touches the real problem.
The assumed churn drop is the number to argue about.
It's a guess in both models, and it's the one a vendor deck will round up. Run your own churn and referral rate through the referral ROI calculator before you build either program. The model also ignores the cash an annual switch brings in up front, so it's a little unfair to loyalty. It's a sketch, not a P&L.
Designing points: what earns and what redeems
A points program is a currency you print, so design it like one. It needs one name, clear earn rules, a known exchange rate and a short list of things to spend it on. Four rules cover most of it:
- Name one currency. Not credits, stars and gems. One name, used everywhere, so your support team never has to translate.
- Earn on outcomes. A review published, an annual plan started, a first integration connected. Not page views.
- Cap earning per event and per month. The review rule pays once per review site, not once per edit.
- Price every point. Fix what a point is worth in account credit, so your finance lead can cost the whole program in their head.
Written down, a set of earn rules can be this short. Every rate in it is ours and hypothetical:
Earn rules (hypothetical; 100 points = $1 of credit)
Review published 1,000 points ($10), once per review site
Annual plan started 2,500 points ($25), once per account
First integration 300 points ($3), once per account
Teammate invited 200 points ($2), up to 5 a monthAt that rate, the $5 of credit an average member earns each month in the worked example is 500 points, or half a review. Once you've written a table like this, nobody on your team has to guess what a point is worth, and nobody in finance has to guess what the program costs.
Redeem into things inside your billing: account credit, a discount, a plan upgrade or extra seats. Each one has a cost you can model, because it shows up on an invoice you already understand. Our guide to choosing referral rewards works through how credit and cash differ in cost.
Dropbox shows the product-native unit done well, even though its program is referral rather than loyalty. A Basic user earns 500 MB of storage per referral, up to 16 GB, and Plus, Family and Professional users earn 1 GB per referral, up to 32 GB. The referred friend gets 500 MB too, according to Dropbox's help page, updated September 30, 2026. The lessons carry over: the reward is something the product makes, it scales with the plan, and it has a ceiling.
You can also skip points entirely, which is the path RefRef takes: each earn rule pays its reward straight into billing. Rewards go out through your connected billing provider (Stripe, Paddle, Polar, Dodo Payments or RevenueCat) as account credit, a discount or a plan upgrade. Not every provider delivers all three, so check its integration page; the Paddle guide, for one, lists discounts and plan upgrades but not account credit. In our judgment, paying the event directly is simpler to run and to audit for a product with a handful of earn rules. There's no balance to explain, no exchange rate to defend, and no pile of unspent points sitting on the books.
Points start to earn their keep once you have many earn rules and a catalogue worth redeeming against. At that point one currency is easier than a dozen separate credits, and members enjoy choosing.
If you can't price a reward in your billing system, don't offer it. Branded hoodies sound cheap until the swag closet turns into a shipping job with customs forms.
Tiers: status that's earned and kept
A tier is a named level of status, like Silver or Gold, that gives your long-time customers better perks. The design question is what the status measures: everything a customer has ever done, or what they've done lately.
Cumulative tiers count everything. Salesforce's Trailhead ranks work this way: Ranger takes 100 badges and 50,000 points, and each rank above it adds the same again. The perk is recognition, so a generous ladder costs little to keep.
Rolling tiers count recent activity, and they're the safer choice when a perk costs you money. Smile.io frames the length as the merchant's call: whether VIP status lasts "for their lifetime or a calendar year" (Smile's blog, March 2024). A calendar year resets everyone on the same morning. A rolling twelve months, which is our preference rather than Smile's, keeps each customer's clock their own.
Our rule: a rolling twelve months for perks that cost you money, lifetime for recognition that doesn't.
A small SaaS version might look like this, built on the worked example's loyalty members. The tiers, thresholds and multipliers are ours and hypothetical:
| Tier | Kept by, over a rolling twelve months | Perk | Credit per member a month |
|---|---|---|---|
| Member | Any earned reward | Standard earn rules | $5 |
| Silver | Three outcomes, such as a review and two milestones | Earn rules pay 1.5 times | $7.50 |
| Gold | An annual plan and five outcomes | Earn rules pay double, plus early access to new features | $10 |
Put 400 of the example's 600 members in Member, 150 in Silver and 50 in Gold, and your monthly loyalty bill goes from $3,000 to $3,625. At the example's $300 per kept customer, that extra $625 has to keep about two more customers a month to pay its way. Early access costs you almost nothing; the multipliers are where the money goes, so price them first.
Whichever shape you pick, write the downgrade rule down, say when it runs, and tell members a month ahead exactly what keeps their tier.
Nobody should lose Gold the week their renewal is due.
Points expiry without the angry emails
Points expiry is the rule that cancels unspent points after a set time. It limits the liability of a balance you've promised but nobody has spent, and it nudges members to redeem. Done badly, it's also the fastest way to turn a loyal customer into a support ticket that opens with "I had a whole balance yesterday."
There are two common designs. A fixed date wipes points on a schedule, whatever the member is doing. Inactivity expiry wipes them only after a quiet spell, and any activity resets the clock. Inactivity is kinder, because the people who lose points are the ones who've already drifted away from you.
Smile.io publishes the clearest public spec, in its help article on points expiry. Points don't expire unless the merchant turns expiry on. Once it's on, any balance change counts as activity, and when the clock runs out the whole balance resets to zero at once. By default, members get a warning 30 days before and a last-chance note 3 days before. Expiry is available on Smile's Growth plan and up, and Growth costs $199 a month as of November 10, 2026.
Expire on inactivity, warn twice.
And never expire points your customer earned this quarter. A whole-balance reset is tidy for the accountant and brutal for the person who was saving up.
If you pay rewards straight into billing, most of this goes away, because there's no points balance for you to expire. The credit or discount comes off a future invoice, and nobody has to remember to spend it.
Running loyalty and referral on one customer record
Two tools mean two identities for one customer. The referral tool knows her as a referrer, the loyalty tool knows her as a member, and the refund rules in each have never met. That's how an annual upgrade can earn credit twice, and nobody notices until finance asks why the credit line doubled.
On one record, a single participant (the person or account your programs reward) can sit in a referral program and a loyalty program at the same time. In RefRef, a participant is one record per Project, identified by your own external ID, and can be enrolled in several programs at once, with one open enrollment per program. A referral event and a review event both land on that person, and loyalty rules fire on any event of their type, referral or not. When a purchase is fully refunded, RefRef takes back a non-cash reward it already delivered; a partial refund leaves it in place. The docs on participants, qualifying events and rewards have the details.
Identify people with your own user ID, every time. The participants page puts it plainly: "One person under two IDs is two participants." Two participants means two reward histories, which is the problem you were trying to avoid.
Whatever tool you use, check that both programs' credits show up in one place you can audit. Otherwise month-end is two filing cabinets and a hopeful handshake.
As of November 10, 2026, Tolt, Rewardful, Dub Partners, GrowSurf, Cello and FirstPromoter have no loyalty program, though FirstPromoter can pay a referral reward in points. The store loyalty apps meet at one price: Smile.io's Growth plan (where its expiry lives), LoyaltyLion's Classic plan and Yotpo's first paid loyalty plan are each $199 a month, and all three are built for online stores.
Those apps have mature store loyalty features, VIP tiers and points expiry among them. They're also priced by monthly orders, as Smile.io's and LoyaltyLion's plans are, and a subscription produces one order a month, so per-order pricing and "earn per purchase" rules have little to count. Our comparisons with Smile.io, LoyaltyLion and Yotpo go through the details.
RefRef, our pick, puts both programs on one record. It runs referral, affiliate and loyalty programs on one platform, and it's open source under AGPLv3; none of the referral tools named above, Dub Partners included, is open source. Loyalty uses the same plans and meter as referral, with no separate loyalty price.
That meter is monthly active participants (MAP): the people who did something counted that month. Dormant members don't add to your bill. There's a free plan for up to 1,000 monthly active participants, with no time limit, and paid plans start at $49 a month. Credit, discounts and plan upgrades cost nothing extra on any plan. Use RefRef Cloud, or self-host it on your own servers (start with the docs).
RefRef is a younger product with a smaller community than the store loyalty apps. That's a real gap. The hedge is the license and the free plan: you can try RefRef Cloud without paying, self-host the AGPLv3 code if you'd rather run it yourself, and reach your data through the REST API and webhooks if it doesn't fit. If you're still sorting out which program types you need, referral vs. affiliate programs covers the other half of the map.
Setting it up in RefRef
Setup is short because the reward lands in billing you already run. You'll need your billing provider connected and a way to send events from your backend.
- Create a loyalty program. Open
Programs, choose New, and pick the loyalty type. The type can't change later, so don't repurpose a referral program. - Enroll members under your own user ID.
- Send the events you want to reward. Built-in types cover signups and purchases. For anything else, define a type that starts with
custom_, such ascustom_review_publishedorcustom_annual_switch. - Set the reward for each event. Choose account credit, a discount or a custom reward such as a plan upgrade, and decide how often one person can earn it before you switch the rule on.
- Deliver it through billing. Pick a delivery your provider supports; the Stripe and Paddle guides show the settings.
- Test it in the Sandbox. Every Project has a Sandbox twin with its own participants, events and programs. Send one test event and check the credit lands on the right customer before a real one does.
The programs docs describe loyalty programs in full, and pricing has the plan details.
Start with a few earn rules you can explain in one breath.
A program with so many rules that nobody can say what a review is worth has stopped being a program and become folklore.
FAQ
Do SaaS companies need a loyalty program?
Not first. Most SaaS products get more from a referral program until retention or feature adoption becomes the leak. Add loyalty when you have an active base and a clear list of actions worth paying for.
Is a referral program a loyalty program?
No. A referral program rewards someone for bringing in a new customer; a loyalty program rewards customers for their own actions, like a review or an annual switch. They work best on one customer record, so the same person can earn in both without being counted twice.
What should loyalty points be worth in SaaS?
Whatever you can price in billing credit. Pick a rate you can explain, like the hypothetical 100 points to $1 of credit above, and cost every earn rule before launch. Or skip points and pay credit, a discount or a plan upgrade for each action directly.
Start with one earn rule
The cheapest test of all this takes one rule. Sign up for RefRef Cloud on the free plan, create a loyalty program in your Sandbox Project with a single earn rule, and send it a test event. If the credit shows up where you expect, you'll know what the second rule should be. If it doesn't, you've found out before a customer did.