Referral Incentive Design

Referral Incentive Design

Design the reward structure of a customer refer-a-friend program. No canonical named framework exists for this discipline - referral is one letter inside measurement funnels like AARRR, not a design method. What exists is four decision variables, each with its own evidence base, worked through in order because each shapes the next:

1. Sidedness - reward the referrer, the friend, or both (the Reward-Me / Reward-You / Reward-Both taxonomy, Ryu & Feick, _Journal of Marketing_ 2007).
2. Reward type - cash, account credit, discount, product value, status, or donation.
3. Reward size - anchored to gross margin, LTV, and CAC, with a floor set by non-monotonic response (a too-small reward performs worse than none).
4. Payout trigger and tier structure - when the reward fires, and whether rewards escalate with cumulative referrals.

Interview

Ask before recommending anything. One question per message; offer multiple-choice answers when possible. Skip a question only when the user already gave the answer.

• Is the business B2B or B2C? Subscription or one-time purchase? Self-serve or sales-led?
• What are the gross margin, average LTV (or first-year revenue), blended/paid CAC, and entry-plan price?
• Do customers already recommend the product organically? Roughly what share of new customers arrive that way?
• Will the referrer plausibly buy again (account credit has value to them), or not (only cash-equivalents do)?
• For B2B: is the likely referrer the buyer, or an employee whose company pays?
• By what date must this show results? A hard quarter-end date promotes the fast rungs - a flat reward on a first-purchase trigger - and rules out ladders and retention-gated triggers, which need months to read.
• One-off acquisition win, or a compounding asset? Compounding promotes in-kind and status rewards, a tier ladder, and a retention-gated trigger; a one-off win promotes a flat friend-side offer.
• What is the effort ceiling: who builds and administers this, how many hours do they have, and can a published reward be withdrawn later? A low ceiling deletes swag, sweepstakes, and staged payouts outright; a dedicated owner puts the ladder back on the table.

Workflow

1. Run the Interview above; collect every answer the structure depends on before designing.
2. Check the disqualifiers before designing. A referral program captures existing word-of-mouth; it does not create it. No organic referral signal, or an LTV too low to fund a meaningful reward, means the honest answer is "not yet" - say so and stop. Confirm the question is about end-customer referrals, not external affiliates or channel partners (different economics, different tooling; B2B programs tend to migrate from the former to the latter as ACV grows).
3. Decide sidedness, working from references/sidedness-and-triggers.md. Efficiency order: friend-only > double-sided > referrer-only - effort is identical across the three arms, so the value evidence decides, and field experiments found recipient-only rewards matching double-sided rewards that cost twice as much. Lead with friend-only; move to double-sided for an innovative product or a weak brand with weak ties, and to referrer-only only for a genuinely high-effort referral process.
4. Choose the reward type per side from references/reward-types.md, leading with its efficiency order: in-kind product value > account credit == free months > discount > status > cash > swag > charity > sweepstakes. Then apply the criteria that override it:

• Cash-equivalents when the referrer will never rebuy or the product is money-adjacent.
• Status over cash when referring is a public, identity-driven act.
• Charity only ever as a choice.

For B2B, resolve the principal-agent fork (individual reward vs company account credit) explicitly.

1. Size the reward using references/sizing-and-tiers.md: compute the gross-profit ceiling, pick a target inside it starting from the least-effort anchor (% of CAC > % of LTV > payback discipline), verify the floor (non-monotonic response: pay meaningfully or pay nothing), and frame the number with the Rule of 100 (percentage below $100, absolute amount above).
2. Set the payout trigger on a verified value event, never bare signup. Efficiency order: first purchase > qualified activation > closed-won/first invoice > retention threshold > staged payout; promote closed-won for a sales-led B2B motion, and the retention threshold when refund or churn exposure is large. Match the holding period to refund risk and sales-cycle length.
3. Decide whether to tier, against the ladder rules in references/sizing-and-tiers.md. Efficiency order: flat > threshold ladder > stepwise; the ladder is worth its build cost only when volume is high, repeat referrers are plausible, and advocacy concentrates in a few advocates. First tier trivially achievable; top tier always capped - the best-documented failure in this field is an uncapped ladder.
4. Present the four decisions one by one - options considered, trade-offs, and your recommendation - and validate each with the user; revise on pushback before moving to the next.
5. After explicit approval on all four, emit the full structure as a testable spec (next section), grounded in a matching worked example from references/examples.md when one fits the user's situation.
6. If your harness has persistent memory, memorize the approved spec's key decisions and economics - a later diagnosis run starts from them instead of re-interviewing.

Every ordering above ranks value returned per unit of _effort_ - build time, administration, fulfillment, coordination, and how hard the choice is to reverse once published. Never rank by payout size; what a reward costs is a separate axis, and the two disagree often enough that a blended rank hides the case where the cheapest option and the strongest one are different options.

Each order is a default, not a law: it shifts with the situation and with who has to execute it. Re-rank against what you already know about this user before presenting any menu:

• A product whose marginal unit costs near zero promotes in-kind rewards above everything.
• A finance team that refuses cash payouts deletes cash from the menu rather than demoting it.
• An existing rewards platform erases the effort gap that puts ladders and swag near the bottom.

Say out loud which fact moved which option, so the user can argue with the reasoning instead of the row order.

The Reward Structure Spec

Deliver every engagement as this artifact - a decision record the user can hand to product, finance, and a test-plan owner:

REWARD STRUCTURE - <product>, <date>
Sidedness        : both | friend-only | referrer-only, split, disclosure choice
Reward (friend)  : type, amount, framing ("first month free", not "$49 off")
Reward (referrer): type, amount, framing
Payout trigger   : verified event per side + holding period + pending-state display
Tiers            : ladder breakpoints + top-tier cap, or "flat - revisit when <condition>"
Caps             : per-referrer/year, total-earned, program budget ceiling
Economics        : gross-profit ceiling, projected cost per referred customer vs current CAC
Validation       : test arms, % of base exposed, duration, decision metric, incrementality check
KPIs             : participation rate, share-to-signup conversion, cost per incremental referred customer vs CAC

Three rules about the spec itself:

• Every line carries a reason. "Referrer credit fires on the second invoice - survives the refund window" is reviewable; a bare amount is not.