Start a reward discussion with two questions: what action are you asking each customer to take, and how much contribution can that action support? A familiar “give $20, get $20” offer answers neither.
The referrer needs a reason to share a useful recommendation. The new customer needs a reason to try the product. Those are different jobs, so the benefits need not be equal—or even the same type. The constraint is that the combined offer, delivery and operating costs fit the economics you are willing to fund.
The examples below are hypothetical planning scenarios. They are not customer results, reward recommendations for every business, or promises of growth.
Set the budget on a defined horizon
Revenue is not the reward budget. Choose a horizon, then subtract the costs needed to serve that revenue before deciding how much is available for acquisition. For a pilot, a first-payment or short payback horizon is easier to inspect than an optimistic lifetime estimate.
Define “contribution margin” in your own model. Here it means revenue less variable service costs, before referral benefits, program software and incremental program support. Those service costs might include payment processing, infrastructure usage and variable customer support. Fixed company overhead remains outside this simplified model. Do not subtract a cost twice if it is already inside your margin estimate.
Suppose a subscription costs $100 per month and consumes $25 in variable service cost. It contributes $75 before referral costs. If you want to keep at least $40 from the first month, you can spend at most $35 on benefits and other acquisition costs in this simplified first-month model.
Available referral budget = pre-referral contribution − contribution to retain
= $75 − $40
= $35If allocated program and delivery cost is $5 per acquired customer, the two rewards together must fit within $30. Run your assumptions through the referral reward calculator, then check what its cost inputs include. A calculator is only as useful as the boundary around its inputs.
Do not count a discount twice
Consider giving the new customer $10 off the first invoice and the referrer a $20 cash reward. With variable service cost held at $25 for simplicity:
| First-month item | Amount |
|---|---|
| List-price invoice | $100 |
| New-customer discount | −$10 |
| Collected revenue | $90 |
| Variable service cost | −$25 |
| Referrer reward | −$20 |
| Allocated program/delivery cost | −$5 |
| Contribution remaining | $40 |
There are two valid ways to calculate this: start with $75 of pre-referral contribution and subtract $10 + $20 + $5, or start with $90 collected revenue and subtract $25 + $20 + $5. Do not start with discounted revenue and deduct the same $10 again.
Keep taxes, refunds and payment fees consistent with your definition. If a discounted invoice reduces a percentage-based processing fee, refine that cost rather than quietly changing the margin assumption halfway through the calculation.
A future credit has different economics from cash
A $20 reward can mean cash, an invoice credit or additional product usage. The customer may value these similarly, but your cost and delivery obligations differ.
Cash has a direct outflow, plus any transfer or operating fees. A discount reduces the amount collected on a qualifying sale. A credit toward a future invoice can reduce revenue you would otherwise collect if redeemed. Extra product usage can create incremental infrastructure costs and may also replace usage the customer would have bought.
Do not apply the service-cost percentage to every reward and call that its cost. A $20 invoice credit is not automatically a $5 cost just because your normal variable costs are 25% of revenue. Conversely, a bundle of extra compute units should be modeled using both its service cost and any displaced revenue, not only the retail number on the banner.
As a concrete billing distinction, Stripe's customer invoice balance documentation describes a credit applied to a later invoice, with provider-specific constraints. That is different from transferring cash. Confirm the behavior of the system that will actually deliver your offer.
For budget protection, begin by reserving the full face value of promised credits. Once you have your own redemption history, use it for an expected-cost scenario alongside a full-redemption stress case. If 100 customers each earn $20 of credit, face-value exposure is $2,000. At an assumed 60% redemption rate, expected redeemed value would be $1,200. That assumption is not evidence that the other $800 is free money, and this planning calculation does not determine accounting treatment.
Double-sided offers need a combined cap
A two-sided offer can make the invitation easier to explain: the referrer gives something useful and receives something too. It also creates two benefits to fund and two delivery outcomes to track. There is no universal reason to split the budget equally.
For the $30 combined reward allowance above, you might compare $10 for the new customer and $20 for the referrer against $20 and $10. Keep the eligibility, audience and qualification event constant. Otherwise, a better result could reflect who saw the offer rather than the split itself.
Define caps in units an operator can inspect: qualified customers per period, total benefit value, and maximum value per referrer. A budget warning is not an enforced cap. Specify what happens when the cap is reached before customers make plans around an advertised reward.
Use the double-sided policy template to record timing and refund behavior for each side. An earned reward, a pending delivery and an applied benefit should not be described as the same state.
Check incrementality before celebrating ROI
A referral-attributed customer is not necessarily a customer you would have lost without the reward. Some customers were already coming. Treat attribution as evidence of the recorded journey; evaluate additional acquisition separately.
Consider 100 attributed customers who each contribute $75 before referral costs over your chosen horizon. Suppose benefits cost $30 per attributed customer and incremental program costs total $500. Total program cost is $3,500.
If all 100 are additional customers, incremental contribution is $7,500, net gain is $4,000, and modeled ROI is about 114%: ($7,500 − $3,500) / $3,500. At 50% incrementality, contribution is $3,750, net gain is $250, and ROI is about 7%. At 40%, contribution is $3,000 and the program loses $500 on that horizon.
The break-even incremental share is $3,500 / $7,500, or about 46.7%, under these assumptions. Notice that the reward cost still applies to all 100 attributed customers, including those who would have bought anyway. Reducing both the benefits and contribution by the same incremental share hides that cost.
Use the referral ROI calculator for the overall model. Test a pessimistic retention or revenue case as well as your expected case. A holdout or a carefully designed comparison can help estimate lift; a dashboard's referral count alone cannot supply it.
Make the reward easy to trust
The most generous headline is not useful if customers cannot tell when they qualify or where the benefit went. State the qualifying action, review period, delivery timing, limits and important exclusions near the offer. Keep the customer's sharing copy consistent with the terms and show the sender's incentive clearly.
For a first pilot, select a benefit your team can reliably deliver and explain. Record the full-redemption exposure, the contribution floor and the person who handles failed delivery. Review the pilot using retained customers, contribution and support effort, not just invitations sent.
Write those decisions into the SaaS referral program brief. The reward amount is one field in an operating policy. Its economics become useful only when the policy and the implementation agree.