设计客户推荐奖励计划时，如何决定奖励对象、类型…

为面向终端客户的 refer-a-friend 计划设计奖励结构：谁获奖励、奖励什么、给多少、何时发放、是否分级。

适用场景

解决思路

1. 先做访谈，逐条收集设计所依赖的信息（每条消息只问一个问题，尽量给多选项；用户已答的跳过）：B2B 还是 B2C、订阅还是一次性购买、自助还是销售主导；毛利率、平均 LTV（或首年收入）、混合/付费 CAC、入门套餐价格；客户是否已在自然推荐、自然推荐带来的新客占比；推荐人是否可能复购（决定账户积分是否有价值）；B2B 场景下推荐人是买方还是由公司付费的员工；必须出结果的截止日期（硬性季末日期会倾向快速方案：首次购买触发的固定奖励，排除需要数月才能读出效果的阶梯和留存门槛触发）；这是一次性获客还是可复利资产（复利倾向实物与身份类奖励、阶梯、留存门槛触发；一次性倾向朋友侧固定优惠）；执行上限：谁搭建和运营、有多少小时、已公布的奖励能否撤回（低上限直接排除 swag、抽奖、分阶段发放；有专职负责人则可考虑阶梯）。
2. 设计前先检查不合格条件：推荐计划只能捕获已有的口碑，不能创造口碑。没有自然推荐信号，或 LTV 太低无法支撑有意义的奖励，就诚实回答“还不行”并停止。确认问题是关于终端客户推荐，而非外部联盟或渠道伙伴（经济模型和工具不同；B2B 计划随 ACV 增长常从前者迁移到后者）。
3. 决定 sidedness（奖励谁），依据 references/sidedness-and-triggers.md。效率顺序：friend-only > double-sided > referrer-only——三种方案投入的努力相同，因此由价值证据决定；实地实验发现仅奖励接收方即可匹敌成本翻倍的双边奖励。优先 friend-only；对创新产品、弱品牌弱关系用 double-sided；只有推荐过程确实高成本时才用 referrer-only。
4. 按 side 选择奖励类型，依据 references/reward-types.md，先按其效率顺序：in-kind product value > account credit == free months > discount > status > cash > swag > charity > sweepstakes。再应用可覆盖该顺序的准则：推荐人永不复购或产品与钱高度相关时用现金等价物；推荐是公开的、身份驱动的行为时用 status 而非现金；charity 只能作为可选项。B2B 场景显式解决委托-代理分叉（个人奖励 vs 公司账户积分）。
5. 用 references/sizing-and-tiers.md 确定奖励金额：计算毛利上限，在其中选目标，从最省力锚点起步（% of CAC > % of LTV > payback discipline），验证下限（响应非单调：要么给得有意义，要么不给），并用 Rule of 100 表述数字（低于 $100 用百分比，高于 $100 用绝对金额）。
6. 把发放触发设在已验证的价值事件上，绝不用裸注册。效率顺序：first purchase > qualified activation > closed-won/first invoice > retention threshold > staged payout；销售主导的 B2B 动作用 closed-won，退款或流失风险大时用 retention threshold。持有期与退款风险和销售周期长度匹配。
7. 依据 references/sizing-and-tiers.md 的阶梯规则决定是否分级。效率顺序：flat > threshold ladder > stepwise；只有当量大、推荐人可能重复推荐、且倡导集中在少数人身上时，阶梯才值得其搭建成本。第一档应轻易可达；最高档必须封顶——该领域记录最充分的失败就是未封顶的阶梯。
8. 逐条呈现四项决策——考虑过的选项、权衡、你的建议——并逐项与用户确认；遇到反对先修改再进入下一项。
9. 四项全部明确批准后，输出完整结构为可测试的 spec（见下节），并在用户情境匹配时引用 references/examples.md 中对应的完整示例。
10. 如果你的运行环境有持久记忆，记住已批准 spec 的关键决策和经济数据——后续诊断运行可从此开始，无需重新访谈。
11. 注意：以上所有排序按每单位努力（搭建时间、运营、履约、协调、以及一旦公布后多难撤回）带来的价值排序，绝不按奖励金额排序；奖励成本是另一条轴，两者经常不一致，混合排序会掩盖最便宜选项与最强选项并非同一选项的情况。
12. 每个顺序都是默认值而非定律，会随情境和执行者变化；呈现任何菜单前先根据你对用户的已知信息重新排序：边际成本近零的产品把 in-kind 奖励提到最前；拒绝现金发放的财务团队直接把现金从菜单删除而非降级；已有奖励平台会消除让阶梯和 swag 垫底的努力差距。要说出哪个事实移动了哪个选项，让用户能针对推理而非行序提出异议。
13. 交付物统一为 Reward Structure Spec（可交给产品、财务和测试计划负责人的决策记录），包含：Sidedness（both | friend-only | referrer-only、split、披露选择）；Reward (friend)（类型、金额、表述，如“first month free”而非“$49 off”）；Reward (referrer)（类型、金额、表述）；Payout trigger（每侧已验证事件 + 持有期 + pending 状态展示）；Tiers（阶梯断点 + 最高档上限，或“flat - revisit when <condition>”）；Caps（每位推荐人/每年、累计上限、计划预算上限）；Economics（毛利上限、每个被推荐客户的预计成本 vs 当前 CAC）；Validation（测试组、暴露基数百分比、时长、决策指标、增量性检查）；KPIs（参与率、分享到注册转化率、每个增量推荐客户的成本 vs CAC）。
14. spec 本身的三条规则：每一行都带理由（“推荐人积分在第二张发票时发放——能扛过退款窗口”可被审阅，裸金额不行）；验证计划不可省略——sidedness 在从业者与实地研究间确有争议，要写明测试组（both / friend-only / referrer-only，覆盖 5-10% 基数）和增量性检查；增量性检查意味着留出一部分人：获客量持平而 CAC 上升，说明计划在为本来就会来的客户付费。spec 有通过阈值：每个增量推荐客户的预计成本必须低于当前混合 CAC 且落在毛利上限内；反复调整金额、类型或触发直到两者都满足；若无结构能通过，建议不要上线。
15. 诊断已有计划时（用户带着运行中的计划来，如“我们给 $10 积分但没人用”），按效率顺序修复——每单位努力修复最多，而非最便宜的修复优先：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。对应症状：几乎无人分享——先查 ask 的时机与摩擦（位置对参与率的影响大于奖励金额），约一小时，移动提示、改文案，变量不在奖励；有人分享但朋友不转化——查朋友侧优惠强度（朋友的任务更难），约一小时，重新分配已在花的预算，变量是 sidedness/split；加奖励后参与率下降——低于动机下限的象征性金额把人情变成了低薪工作，约一小时配置，代价是永久预算增加，变量是 size；强力推荐人薅阶梯——缺少最高档上限或注册即触发，约一周，且给已公布阶梯封顶是这里最难落地的改动，变量是 tiers/trigger；B2B 推荐人拒收奖励——与公司礼品政策冲突，约一个季度，财务、采购、法务都要碰，变量是 type：改用双轨模式（公司积分 + 可选个人小礼）；推荐量健康但 CAC 上升——增量性问题，奖励在为自然口碑付费，约一个季度，设计 holdout 并等完整周期读出，变量是 economics：跑 holdout，然后把奖励收窄到自然触达低的细分。
16. 注意该修复顺序把增量性 holdout 排在最后（按比率），但它最接近真相，因为它是唯一能揭示整个计划在为本来就会来的客户付费的检查。当推荐量看起来健康而 CAC 攀升时立即提升它——这是唯一没有便宜修复能解释的症状。其余项也要按用户约束重排：本季度无法上线 UI 的团队无法 reposition the ask，这会把 split reweight 推到最前。
17. B2B 与 B2C 在这些方面完全相同，不要各自重造：四项决策及其顺序、毛利上限、非单调下限、Rule of 100 表述、基于已验证价值事件的发放触发、增量性折扣。要明确说出的不对称：本技能依赖的实地实验和学术结果绝大多数是消费侧的；把这里每个数字都当作 B2C 实测、B2B 推断，并在为 B2B 计划提供建议时说明。B2B 与 B2C 的差异维度：谁被奖励（B2C 是客户即付款人；B2B 常是不付款的员工——在第 4 步显式解决委托-代理分叉）；奖励载体（B2C 是个人账户积分或现金等价物；B2B 默认公司账户积分，个人奖励首先是礼品政策和采购问题，其次才是激励）；发放触发（B2C 是首张已付发票或激活里程碑；B2B 更晚——closed-won 或留存门槛，因为周期更长、退款敞口更大）；规模上限（B2C 在规模下成立；B2B 真实存在：随 ACV 增长，客户推荐计划会迁移为联盟或伙伴计划，要留意迁移信号而非把本结构硬撑过去）；披露敏感度（B2C 中等；B2B 更高——推荐人向自己人脉推荐供应商，带有其雇主可能也会管的重大利益关系）。
18. 相关参考：面向专业联盟和伙伴的佣金设计见 mbfinotti/partnerships-skills@affiliate-commission-structure；围绕上限的执行层（速度限制、冷却期、突发检测、验证门槛，以及让上限站得住的公布措辞）见 mbfinotti/partnerships-skills@referral-abuse-guardrails——本技能设定上限值，那个技能让上限成立。

适用边界 · 注意事项

• 不要用于面向专业联盟或渠道伙伴的佣金设计——经济模型和工具不同，应使用 mbfinotti/partnerships-skills@affiliate-commission-structure。
• 没有自然推荐信号，或 LTV 太低无法支撑有意义的奖励时不要设计——推荐计划只能捕获已有口碑，不能创造口碑，应诚实回答“还不行”并停止。
• 不要按奖励金额排序选项，也不要混合排序——奖励成本是另一条轴，混合排序会掩盖最便宜选项与最强选项并非同一选项的情况。