OverviewHistoryStatsSecurity
npx skills add ...
Documentation
SKILL.md
npx skills add mbfinotti/partnerships-skills --skill referral-incentive-design
Design the reward structure of a customer refer-a-friend program - who gets rewarded (referrer, friend, or both), reward type (cash, account credit, discount, product value, status), how much to pay against LTV/CAC and gross margin, when the payout fires, and whether to build a tiered reward ladder. Use whenever the user mentions referral incentives, refer-a-friend rewards, referral bonus amounts, give-X-get-Y offers, double-sided referral rewards, or asks how big a referral reward should be, even if they never say incentive. Covers end-customer rewards only. Do NOT use for commission rates paid to professional affiliates - use mbfinotti/partnerships-skills@affiliate-commission-structure instead.
npx skills add mbfinotti/partnerships-skills --skill 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:
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.
Run the Interview above; collect every answer the structure depends on before designing.
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).
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.
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:
For B2B, resolve the principal-agent fork (individual reward vs company account credit) explicitly.
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).
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.
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.
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.
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.
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:
Say out loud which fact moved which option, so the user can argue with the reasoning instead of the row order.
Deliver every engagement as this artifact - a decision record the user can hand to product, finance, and a test-plan owner:
Three rules about the spec itself:
When the user arrives with a running program instead of a blank page ("we give $10 credit and nobody uses it"), work the fixes in efficiency order - most program repaired per unit of effort, which is not the same as the cheapest fix first:
efficiency: reposition the ask > reweight the split toward the friend > raise the size above the floor > cap the ladder and move the trigger > switch reward type > run the incrementality holdout
| Symptom | Check first | Effort | Variable at fault |
|---|---|---|---|
| Few customers ever share | Timing and friction of the ask - placement moves participation more than reward size does | An hour - move the prompt, change the copy | None - fix the ask before touching the reward |
| Shares happen, friends do not convert | Friend-side offer strength - the friend has the harder job | An hour - reweight a budget you are already spending | Sidedness/split |
| Participation dropped after adding a reward | Token amount below the motivation floor turned a favor into a badly paid job | An hour of config, against a permanent budget increase | Size |
| Power referrers milk the ladder | Missing top-tier cap or signup-fired trigger | A week - and capping a published ladder is the hardest change here to make stick | Tiers/trigger |
| B2B referrers decline rewards | Corporate gift policy collision | A quarter - finance, procurement and legal all touch it | Type: switch to the two-track pattern (company credit + optional individual token) |
| Healthy referral volume, rising CAC | Incrementality - rewards paying for organic word-of-mouth | A quarter - design the holdout, wait out a full cycle to read it | Economics: run the holdout, then narrow the reward to low-organic-reach segments |
The order starves the incrementality holdout: it lands last on ratio and first on truth, because it is the only check that can reveal the whole program is buying customers who were coming anyway. Promote it immediately when referral volume looks healthy while CAC climbs - that is the one symptom no cheap fix explains. Re-rank the rest against the user's constraints too: a team that cannot ship UI this quarter cannot reposition the ask, which pushes the split reweight to the top.
Identical in both, whether B2B or B2C:
Do not reinvent any of them per side.
The evidence base is the asymmetry worth stating out loud: the field experiments and academic results this skill leans on are overwhelmingly consumer-side. Treat every number here as B2C-measured and B2B-inferred, and say so when advising a B2B program.
| Dimension | B2C | B2B |
|---|---|---|
| Who is rewarded | The customer, who is also the payer | Often an employee who is not the payer - resolve the principal-agent fork explicitly at step 4 |
| Reward vehicle | Account credit or cash-equivalent to the individual | Company account credit by default; an individual reward is a gift-policy and procurement question before it is an incentive |
| Payout trigger | First paid invoice or an activation milestone | Later - closed-won or a retention threshold, because the cycle is longer and refund exposure larger |
| Scaling ceiling | Holds at scale | Real: as ACV grows, customer-referral programs migrate into affiliate or partner programs. Watch for the migration signal rather than stretching this structure past it |
| Disclosure sensitivity | Moderate | Higher - a referrer recommending a vendor to their own network carries a material connection their employer may also police |
mbfinotti/partnerships-skills@affiliate-commission-structure for commission design aimed at professional affiliates and partners.mbfinotti/partnerships-skills@referral-abuse-guardrails for the enforcement layer around caps - velocity limits, cooldowns, burst detection, verification gates, and the published wording that makes a cap stick. This skill sets the cap values; that skill makes them hold.