Turn customer introductions into new business accounts.
A B2B SaaS referral can start with one person and end with a team subscription. Design around the account you acquire, the person making the introduction, and a reward your business can support.
RefRef · Program design notes · Updated October 3, 2026
One account. Several people. One acquisition.
A champion shares a link, a colleague evaluates the product, and an administrator purchases. Decide whether your referrer is the champion as an individual or their business account. Treat the new customer account consistently through signup, purchase, and renewal.
Account-to-account
The existing business account owns the code and receives the benefit. The new business account is the referee. Your application decides which team members can access the shared link.
Individual-to-account
An individual owns the code; the new business account is the referee. Check the customer’s gift and procurement policies before promising the individual a personal benefit.
In RefRef, a business account can be a group Participant. The person who performs an Event can be recorded separately as its actor. RefRef does not infer account membership or merge people by email domain; your backend supplies the stable identities.
Reward a qualified purchase, then review delivery.
Example design: enroll existing customer accounts, give each a referral link, and offer a one-time $40 account credit after a new referred account’s first eligible $200 purchase. This is an illustrative offer for your product, not a RefRef plan or a ready-made promotion.
- Define “new customer” and the attribution window before sharing the offer. A trial signup can establish the relationship without earning the purchase reward.
- Send purchase facts from your backend with stable source identifiers and verified paid-history evidence for purchase reward evaluation. Your application must also enforce the offer’s new-customer policy; RefRef does not decide whether an account has ever been your customer.
- Review the reward and any refunds before your billing system applies the credit. Define a delivery schedule and what happens if a refund arrives after delivery.
- Compare retained paid accounts and collected revenue with your other acquisition channels. Count team invitations within an existing account separately.
RefRef records earned Rewards and economic adjustments. The example’s credit application and delivery schedule belong to your operations and billing process. Connect reward webhooks or the reward event feed to your backend to apply credit once per Reward ID and confirm fulfillment, or start with operator-reviewed manual delivery. A recorded adjustment does not withdraw an already delivered benefit.
A three-month contribution check.
| Input or result | Illustrative amount |
|---|---|
| Collected subscription revenue | $200 × 3 = $600 |
| Variable service cost at an assumed 20% | $600 × 20% = $120 |
| Contribution before referral costs | $600 − $120 = $480 |
| One-time reward, budgeted at full face value | $40 |
| Incremental sales and onboarding cost | $100 |
| Contribution after these costs | $480 − $40 − $100 = $340 |
If the account leaves after one paid month, the same model leaves $20: $200 − $40 service cost − $40 reward − $100 onboarding. If both sides receive $40, that one-month result becomes −$20. Test early churn before adopting a double-sided offer.
This model excludes fixed overhead, tax, and other acquisition spending; include payment fees and support in your own variable costs. It is not a profit forecast. Budget credits at face value first, then model actual redemption and any displaced future revenue separately.
Keep account authority on your backend.
RefRef’s role
Program enrollment, referral codes and links, browser handoff attribution, purchase qualification, and reward accounting. The sharing Widget can display a participant’s link.
Your application’s role
Account membership, permission to access a group’s link, trusted signup and purchase facts, billing adjustments, delivery records, and customer communications.
Capture the signed browser handoff through your trusted backend. Capture alone is not a referral: accepted facts and evidence establish the relationship. Keep Project secrets and API credentials out of the browser.
For subscriptions, decide whether the reward stops after one eligible purchase or continues under recurring terms. RefRef’s renewals inherit the Subscription’s recorded origin; do not treat every renewal as a fresh referral opportunity.
For bootstrapped and developer-led teams.
A small team can begin with one Program, a fixed reward, a bounded invitation cohort, and a documented manual delivery process. Set the cohort budget before invitations go out; do not assume the referral engine enforces your company-wide spending limit.
A developer-led product still needs to distinguish a personal sandbox from a paid team account. Decide how that transition supplies the canonical account identity before implementing referral capture. If your service runs expensive AI workloads, also use the AI SaaS reward economics.
Billing reference
Write the operating rules in the SaaS referral program brief, then check the example against your own inputs in the referral ROI calculator.
Invoice credit is a billing action with its own rules. Stripe’s customer credit balance documentation explains its balance and invoice behavior. This reference does not imply that RefRef supplies a Stripe credit-delivery integration.
Bring your program brief.
Tell us who refers, what qualifies, and how you will deliver the benefit. RefRef’s external onboarding is not yet generally available; discuss your integration and rollout with the team.
Discuss your setup