推荐：设计值得推荐的旅程

01. 定义可接受的推荐。

确定谁可以推荐，谁可以成为被推荐人，以及什么构成新的关系。已经在谈判中的潜在客户不一定是新联系人。选择与您的销售周期相匹配的归因窗口，并解释如何处理相互竞争的推荐。信息的简洁性正是基于这一精准的决策。

• 写明资格要求和排除条款。
• 当两位推荐人声称获得同一推荐时，指定权威来源。

02. 区分两条路径。

推荐人必须了解要分享的内容以及奖励何时生效。被推荐人必须在不了解项目的情况下理解优惠内容。优先使用推荐人可以自由分享的链接，而不是自动收集地址。检查适用于渠道和受众的潜在客户开发规则；加入项目并不意味着同意接收所有信息。

• 设计两条移动路径：推荐、发现和转化。
• 审核信息消息和沟通选项。

03.明确奖励的获取点

报价请求、签名和首张已付款发票的价值并不相同。选择一个可验证的事件，并明确验证前的时间范围。如适用，请描述取消或撤回的影响。避免将仍受重要条件限制的利益视为既定事实。

• 区分以下状态：已发送、已接收、进行中、已验证和已取消。
• 为每种状态添加简短说明，供推荐人查看。

04. 平衡奖励及其成本

为推荐人提供奖励，并为被推荐人提供优惠，可以减少推荐过程中的尴尬。分别测试奖励和被推荐人的感知价值和实际成本。预算应包含平台、管理、交付和案例处理等费用。高额奖励并不能弥补方案理解不清或服务不尽如人意的问题。

• 计算每位已验证新客户的成本，包括所有项目。
• 根据最终转化率和获客质量比较不同方案。

05. 做好应对模糊案例和欺诈的准备

预估重复购买、链接失效、取消购买和自我推荐等情况。控制措施必须适度：仅凭共享的电子邮件地址不足以证明存在欺诈行为。保留决策记录，并制定人工审核争议的计划。不要让参与者依赖于不透明的状态。

• 创建包含决策理由和责任人的决策矩阵。
• 建立申诉流程、响应时限和审计日志。

06. 将程序与业务周期连接起来。

CRM 系统必须传输验证推荐的事件。测试推荐、文件和客户之间的关联，避免不必要的数据记录。推荐码丢失不应导致更正过程中出现重复付款。定期核对销售状态和已发放奖励。

• 测试重复发送的事件、合并的文件以及延迟取消的情况。
• 明确 CRM 系统与平台之间差异的责任人。

07. 衡量推荐的质量。

跟踪邀请、访问、合格推荐、已验证客户和已发放奖励。使用稳定的分母计算每个指标。同时观察在类似时间段内获取客户的留存率或价值。共享链接数量的增加并不能证明客户获取量增加或盈利能力提高。

• 比较不同用户群的总成本、转化率和客户质量。
• 每次只进行一项调整，以了解其效果。

需要与团队验证的案例研究

• 推荐流程顺利完成：每个角色都能找到自己的步骤并获益。
• 潜在客户即为现有客户：该规则明确区分了不符合条件的情况和潜在的新商机。
• 同一人收到两份邀请：应用分配规则，不重复奖励。
• 已取消或延迟验证的交易：处理过程符合既定条件。
• 通信偏好发生变更：相关工具会进行相应更新，而不会错误地删除业务文件。