referral-incentive-design

推荐奖励设计

设计客户好友推荐计划的奖励结构。该领域没有公认的命名框架——推荐只是 AARRR 等衡量漏斗中的一个环节，而非一种设计方法。现有的是四个决策变量，每个变量都有各自的证据基础，并按顺序逐一处理，因为每个变量都会影响下一个：

1. 奖励对象——奖励推荐人、好友，还是双方（Reward-Me / Reward-You / Reward-Both 分类法，Ryu 和 Feick，《Journal of Marketing》2007 年）。
2. 奖励类型——现金、账户额度、折扣、产品价值、身份地位或捐赠。
3. 奖励金额——以毛利、LTV 和 CAC 为依据，同时设定一个底线，以应对非单调响应（奖励太少，效果反而不如不奖励）。
4. 奖励发放触发条件和阶梯结构——何时发放奖励，以及奖励是否随累计推荐人数增加而递增。

访谈

提出建议前先提问。每条消息只问一个问题；尽可能提供多项选择答案。只有当用户已经给出答案时才跳过问题。

• 企业面向 B2B 还是 B2C？采用订阅还是一次性购买模式？是自助服务还是销售主导？
• 毛利、平均 LTV（或首年收入）、综合／付费 CAC 和入门方案价格分别是多少？
• 客户是否已经会自发推荐产品？大约有多少新客户是通过这种方式来的？
• 推荐人是否可能再次购买（账户额度对他们有价值），还是不会（只有现金等价物才有价值）？
• 对于 B2B：可能的推荐人是买家，还是由公司付费的员工？
• 必须在什么日期前看到效果？如果季度末是硬性截止日期，就应采用见效快的方案——首次购买触发的固定奖励，并排除阶梯奖励和以留存为条件的触发方式，因为评估这些方案需要数月时间。
• 是追求一次性的获客成果，还是打造可持续积累的资产？若追求持续积累，应优先考虑实物奖励和身份地位奖励、阶梯奖励以及以留存为条件的触发方式；若追求一次性成果，则应优先考虑面向好友的固定优惠。
• 工作量上限是多少：由谁构建和管理，能投入多少小时，已公布的奖励之后能否撤回？如果工作量上限较低，就应直接排除周边商品、抽奖和分阶段发放奖励；如果有专人负责，则可以重新考虑阶梯奖励。

工作流程

1. 进行上述访谈；在设计前收集所有会影响方案结构的答案。

2. 设计前检查否决条件。推荐计划只能捕捉已有的口碑传播，无法创造口碑传播。如果没有自然推荐信号，或 LTV 太低、无法承担有意义的奖励，就应坦诚回答“暂时不适合”并停止。确认讨论的是终端客户推荐，而非外部联盟或渠道合作伙伴（经济模式和工具各不相同；随着 ACV 增长，B2B 计划往往会从前者转向后者）。

3. 参考 references/sidedness-and-triggers.md，决定奖励对象。效率顺序：仅奖励好友 > 双向奖励 > 仅奖励推荐人——三种方案的工作量相同，因此应依据价值证据作出决定；实地实验发现，仅奖励接受推荐的一方，效果与成本翻倍的双向奖励相当。优先采用仅奖励好友；对于创新型产品或品牌较弱且关系较疏远的情况，改为双向奖励；只有推荐流程确实需要投入大量精力时，才仅奖励推荐人。

4. 按照 references/reward-types.md，为各方选择奖励类型，并优先遵循以下效率顺序：实物产品价值 > 账户额度 == 免费月数 > 折扣 > 身份地位 > 现金 > 周边商品 > 慈善捐赠 > 抽奖。然后应用以下可覆盖该顺序的标准：

   • 如果推荐人永远不会再次购买，或产品与金钱关系密切，应使用现金等价物。
   • 如果推荐是一种公开且由身份认同驱动的行为，应优先选择身份地位奖励，而非现金。
   • 只有在用户可自行选择时，才提供慈善捐赠。

   对于 B2B，应明确处理委托代理分歧（奖励个人还是提供公司账户额度）。

5. 根据 references/sizing-and-tiers.md 确定奖励规模：计算毛利上限，从最省力的基准开始，在上限内选定目标（CAC 占比 > LTV 占比 > 回本纪律），核实底线（响应是非单调的：要么给出有意义的奖励，要么什么都不给），并用 100 规则来表达金额（低于 $100 时用百分比，高于 $100 时用绝对金额）。

6. 将奖励发放条件设为经过验证的价值事件，绝不能仅凭注册触发。效率顺序：首次购买 > 合格激活 > 成交 / 首张发票 > 留存门槛 > 分阶段发放；对于销售驱动的 B2B 模式，将成交提升优先级；退款或流失风险较高时，将留存门槛提升优先级。根据退款风险和销售周期长度设定等待期。

7. 根据 references/sizing-and-tiers.md 中的阶梯规则决定是否设置奖励阶梯。效率顺序：固定奖励 > 门槛阶梯 > 分档奖励；只有在量大、有可能出现重复推荐者，且推广意愿集中在少数推荐者身上时，阶梯才值得投入构建成本。第一个阶梯必须轻松可达；最高阶梯必须始终设有上限——这个领域中记录最充分的失败案例就是未设上限的阶梯。

8. 逐一说明这四项决策——考虑过的选项、权衡和建议——并逐项请用户确认；如用户提出异议，先修订再进入下一项。

9. 用户明确批准全部四项后，将完整结构输出为可测试的规范（见下一节）；如果 references/examples.md 中有与用户情况匹配的实例，就以该实例为依据。

10. 如果你的运行环境支持持久化记忆，请记住已批准规范中的关键决策和经济指标——之后进行诊断时，应以此为起点，而不是重新询问用户。

以上每种排序衡量的都是每单位_投入_带来的价值——构建时间、管理、履约、协调，以及发布后修改决策的难度。绝不要按奖励金额排序；奖励的成本是另一条独立维度，而两者经常不一致，混合排序会掩盖最便宜的选项和最有效的选项并不相同的情况。

每种排序都是默认建议，而非铁律：具体排序会随情况和执行者而变化。在给出选项列表前，先根据你已了解的用户情况重新排序：

• 如果产品的边际单位成本接近零，应将实物奖励提升到所有其他选项之上。
• 如果财务团队拒绝现金奖励，就应从选项中删除现金奖励，而非仅降低其优先级。
• 如果已有奖励平台，就不再存在导致阶梯和周边产品选项排名靠后的投入差距。

明确说明哪些情况改变了哪些选项的排序，让用户可以质疑你的推理，而不只是质疑列表顺序。

奖励结构规范

每次交流都要交付以下成果——一份决策记录，用户可以交给产品、财务和测试计划负责人：

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

关于规范本身，有三条规则：

• 每一行都要说明理由。“推荐者奖励在第二张发票开具时发放——退款窗口已过，风险较低”是可供审阅的；只写金额则不行。
• **验证计划并非可选项。**从业者和实地研究对奖励对象是双边还是单边确有分歧，因此要明确列出测试组（双方 / 仅朋友 / 仅推荐者，覆盖 5-10% 的基础用户），并进行增量性检查。增量性检查意味着保留一部分用户不参与计划：如果获客量持平而 CAC 上升，就说明该计划为本来就会到来的客户付了奖励。
• **规范必须设定通过门槛。**预计每位增量推荐客户的成本必须低于当前综合 CAC，且不超过毛利上限。调整奖励金额、类型或触发条件，直到两项都满足；如果没有任何结构达标，就建议不要上线。

诊断现有计划

当用户带着一个正在运行的计划而非一张白纸来找你时（“我们提供 10 美元的额度，但没人使用”），请按效率顺序处理修复项——即单位投入所能修复的计划问题最多，而不是先做成本最低的修复：

效率：调整邀请时机和位置 > 调整分配比例，让好友获得更多 > 将奖励金额提高到门槛以上 > 为阶梯奖励设置上限并调整触发条件 > 更换奖励类型 > 开展增量效果对照测试

症状	优先检查项	投入	出问题的变量
很少有客户分享	邀请的时机和阻力——调整位置对参与度的影响大于奖励金额	一小时——移动提示位置、修改文案	无——先优化邀请，再调整奖励
有人分享，但好友没有转化	好友一侧的优惠力度——好友承担的任务更难	一小时——重新分配现有预算	双边奖励/分配比例
添加奖励后参与度下降	奖励金额低于激励门槛，把一份人情变成了报酬过低的工作	一小时的配置工作，相比永久增加预算	金额
高活跃推荐者薅尽阶梯奖励	缺少顶级奖励上限，或触发条件设为注册时	一两天——而且要让已公布的阶梯奖励上限真正生效，是这里最难落实的改动	阶梯/触发条件
B2B 推荐者拒绝奖励	与公司礼品政策冲突	一个季度——财务、采购和法务部门都要参与	类型：改为双轨模式（公司额度 + 可选的个人代币）
推荐量健康，但 CAC 上升	增量效果——奖励可能付给了自然口碑带来的客户	一个季度——设计对照组，等待完整周期后再评估	经济效益：开展对照测试，然后将奖励范围缩小到自然触达率低的细分群体

这个顺序把增量效果对照测试排在最后，因为它最耗资源；但它揭示真相的能力最强，因为只有这项检查能揭示整个计划是否只是在为本来就会来的客户买单。若推荐量看起来健康但 CAC 却在上升，应立即把它提到首位——这是唯一无法用廉价修复解释的症状。还要根据用户的限制重新排列其余项目：如果团队本季度无法发布 UI，就无法调整邀请位置，因此应把调整分配比例提到首位。

B2B 与 B2C

无论是 B2B 还是 B2C，以下内容都完全相同：

• 四项决策及其顺序。
• 毛利上限。
• 非单调下限。
• Rule of 100 的框架。
• 在经过验证的价值事件发生时触发奖励。
• 增量性折减。

不要针对任一方重新设计这些内容。

值得明确说明的是，证据基础存在不对称性：本技能所依据的实地实验和学术研究几乎都来自消费者端。请将这里的每个数字都视为基于 B2C 测量、在 B2B 中推断得出，并在为 B2B 计划提供建议时说明这一点。

维度	B2C	B2B
奖励对象	客户，同时也是付款方	通常是并非付款方的员工——请在步骤 4 明确解决委托人—代理人分歧
奖励形式	账户抵用金或等同现金的个人奖励	默认采用公司账户抵用金；个人奖励首先涉及礼品政策和采购问题，而非激励问题
奖励触发条件	首张已付款发票或激活里程碑	更晚——赢得交易或达到留存门槛，因为周期更长，退款风险敞口也更大
扩展上限	规模扩大后仍然适用	确实存在：随着 ACV 增长，客户推荐计划会转向联盟或合作伙伴计划。留意这种转变的信号，不要让当前结构超出其适用范围
披露敏感度	中等	更高——推荐人向自己的人脉圈推荐供应商，存在重大利益关联，其雇主也可能对此进行监管

调用示例

• “为月费 $49、利润率 80%、平均留存期 14 个月、付费 CAC 为 $220 的 B2B SaaS 设计好友推荐奖励。”
• “我们给推荐双方各 $10 抵用金，但没人使用。诊断四个变量中哪个出了问题。”
• “我们的推荐奖励应该分级吗？大约 8% 的客户会推荐，还有少数客户会反复推荐。”

参考

• mbfinotti/partnerships-skills@affiliate-commission-structure，用于面向专业联盟伙伴和合作伙伴的佣金设计。
• mbfinotti/partnerships-skills@referral-abuse-guardrails，用于围绕上限设置执行机制——频率限制、冷却期、突发检测、验证关卡，以及确保上限有效的公开措辞。本技能设定上限值；该技能确保上限得到执行。