Referral and Recommendation Systems

Most referral programs are born in a meeting: “Let's give $10 to whoever invites someone.” Three weeks later the campaign is live, a month later the chart is flat. The team doubles the reward, the chart twitches, then stalls again. Everyone concludes the reward is too small.

Most of the time the reward is not the problem. The user either wants to tell people about the product or does not; the program only makes that tendency easier or ignores it. Paying someone who does not want to talk about your product is expensive, and it usually produces low-quality invitations.

When you need it

Referral kicks in when a core of people who love the product already exists. Signals:

• A visible share of new customers say “a friend recommended it,” though you have never encouraged it.
• You have a strong promoter group in your NPS or Ellis survey, and they already talk on their own.
• Acquisition cost is rising, while your existing customers' circles are a natural audience.
• The product sits in a category where recommending it to peers is natural (finance, health, B2B tools, services).

Where it is too early: if retention is low, or customers see the product as “good enough,” a referral program just spreads a bad experience faster. First secure attachment rather than satisfaction: does the user stop at “nice product,” or make it part of their own work?

What most teams miss

Treating referral as a reward problem misses its real nature: it is a product flow problem. Dropbox's well-known program is the example. Dropbox gave extra storage to both the person who invited and the person invited. Two features mattered. The reward was in the same unit as the product's own value (storage), so it meant something to every user and its marginal cost to the company was low. And the reward was two-sided; the inviter did not feel they were exploiting a friend, they were giving a gift.

The lesson is that a good reward comes from inside the product. Cash attracts everyone, including people who do not like the product. A discount or extra usage speaks to the person who would like the product anyway and does not pull the wrong people into the program. The Dropbox reward made the program part of the acquisition process itself: the invited person saw the product's value and the reward together from day one.

Referral is not paying users. It is opening a door for them at the moment they want to talk.

Timing matters as much as the reward. A user is most inclined to recommend when the product has just given them the most value: after a successful transaction, after solving a problem, after hitting a milestone. Where and when the program appears is often more decisive than the size of the reward; a modest invitation on the success screen does more work than a generous one hidden in account settings. Putting the invitation request in the first minute after signup is the classic mistake; a user who has seen no value yet has nothing to recommend.

The difference from the virality piece: in virality, the use of the product itself generates spread; referral is a deliberate act of inviting, and you have to design that act.

The playbook

1. Identify your natural advocates

Who is already recommending you? Ask customers “how did you hear about us?” in forms and calls. In the answers, find out who does the recommending: which segment, role and usage level. Aim the program at that group first.

2. Define the recommendation moment

On your product map, mark the two or three moments when the user feels the value most clearly (first successful result, repeated use, positive feedback, a milestone). Show the invitation prompt only at those moments.

3. Build a two-sided reward tied to the product

Give both the inviter and the invitee a value that comes from inside the product: extra usage, an extended trial, an upgraded plan. Work out the cost. Set a hard line: reward plus operations cost must stay below the CAC you would happily pay for that customer.

4. Push invitation friction toward zero

A one-click share link, a suggested personal message, picking from a contact list, showing the invitee's reward on the first screen. If the invitation flow has more than three steps, usage drops.

5. Plan for abuse from the start

Fake accounts, self-invitations, reward hunting. Tie the reward to the invitee completing a real activation action (first payment, first task). Giving the reward at signup opens the door to fraud.

What to measure

• Share of users who send invitations: How many active users send at least one? A leading indicator of the program's visibility.
• Invitation-to-activation conversion: How many invitees actually get value. A more honest number than invitations sent.
• Retention of referred customers: Do people who arrive by recommendation stick better? That difference is the program's proof of value.
• Acquisition cost per referral: Including reward and operations cost, compared with channel CAC.

Pitfalls

Putting the program at the edge of the product. A hidden tab in account settings, a link nobody will find. Referral must be visible and meet users at the right moment.

Choosing a reward unrelated to the product. Cash or gift cards attract users who do not like the product but want the reward; quality drops and support load rises.

One-sided reward. A reward only for the inviter makes the user feel like they are selling a friend. A two-sided reward turns the invitation into a favor.

Start this week

1. Ask everyone who signed up in the last 30 days “how did you hear about us?” and work out the share who came by recommendation.
2. Identify the two moments where users see value most clearly in your product and draft an invitation prompt for each.
3. Calculate the cost of the proposed reward against the estimated lifetime value of a referred customer and put it in front of the team on one page.