阅读定位：这是 VIPKID 增长引擎拆解 的姊妹篇。上一篇我从增长视角拆了 VIPKID 为什么必须依赖销售、班主任、体验课和转介绍；这一篇我从系统视角补全同一个问题：这台人力驱动引擎，下面到底铺了什么基础设施，它托住了什么，又没托住什么。
上一篇讲引擎，这一篇讲基础设施
上一篇里，我把 VIPKID 的增长引擎拆成了三件事：
- 转介绍飞轮
- 阶梯式变现
- 通时通次考核
但引擎不会自己转。
如果没有一套系统把 lead、销售、体验课、班主任、教学反馈、续费提醒和推荐关系串起来，这些动作就只能停留在“组织很勤奋”。组织一旦变大，信息就会断，动作就会慢，责任就会模糊，最后增长引擎空转。
我在 VIPKID 亲手做过其中一部分支撑系统。所以这篇我不想写成“CRM 功能介绍”，而是想回答一个更有用的问题：
当你的增长引擎是人力驱动型时，CRM 到底应该承担什么角色？
先把上一篇和这篇的关系钉死：
| 上一篇的增长杠杆 | 这一篇对应的系统能力 |
|---|---|
| 转介绍飞轮 | 推荐关系关联、邀请归因、奖励自动发放 |
| 阶梯式变现 | lead 分流、体验课预约、销售跟进、续费提醒 |
| 通时通次考核 | CRM 和呼叫中心打通、行为记录、管理监控 |
如果说上一篇回答的是“为什么这台引擎能跑”，这一篇回答的就是“它靠什么不至于散架”。
先说边界：这里的 CRM 不是狭义销售软件
如果把 CRM 理解成“录客户资料的地方”，那 VIPKID 这篇很容易写歪。
因为 VIPKID 真正的系统现实是：
- lead 要从投放和转介绍进入
- 前面有 TMK 外呼筛选
- 销售要在 CRM 里直接约体验课
- 体验课要和排课系统打通
- 教学结果要从教学系统回流
- 通话要和呼叫中心打通
- 转介绍要和 App 端邀请机制打通
所以这里说的 CRM，更接近一个运营中枢，而不是单独一套销售软件。
它的作用不是“把所有东西都装进去”，而是把关键业务信息和关键业务动作连接起来。
我这篇不讲底层架构，不讲技术栈，也不讲数据库表设计。我只讲三件事：
- 业务当时要解决什么问题。
- 系统怎么把这些问题结构化。
- 哪些问题系统其实解决不了。
这点先说清，后面就不会在“这是不是严格意义上的 CRM”上纠缠。
先给总图：增长引擎反推系统模块
VIPKID 这类业务，业务链路大概长这样：
线索进入
→ 前置筛选
→ 销售跟进
→ 体验课预约与完成
→ 首次付费
→ 班主任接手
→ 学习持续
→ 续费
→ 转介绍如果从系统设计角度反推，它对应的不是一个“万能 CRM”，而是一组必须咬合的系统能力：
| 业务链路 | 系统能力 |
|---|---|
| 线索进入 | 来源打标、归因、分池 |
| 前置筛选 | TMK 话术、字段采集、线索过滤 |
| 销售跟进 | 外呼记录、SLA 可视化、预约动作 |
| 体验课 | CRM 与排课系统打通 |
| 首次付费 | 订单创建、交接触发 |
| 交接 | 销售信息、试听回放、定级建议可见 |
| 学习持续 | 教学报告回流、节点任务 |
| 续费 | 到期提醒、课时预警、任务触发 |
| 转介绍 | 推荐关系、邀请链接、奖励发放 |
我下面会按这条链路拆五个环节。每一节都只回答四个问题：
- 这个环节要解决什么业务问题？
- VIPKID 当时怎么做？
- 系统到底解决了什么？
- 抽出来的通用原则是什么？
一、获客支撑：先把线索分清，再谈转化效率
VIPKID 的一个误区是，外部很容易把它理解成“流量来了，销售去打”。
但内部真正麻烦的是：不同来源的 lead，质量完全不一样。
| 线索来源 | 典型特征 |
|---|---|
| 投放 lead | 量大，意向分布广，需要更强筛选 |
| 转介绍 lead | 量相对小，但信任基础更好 |
| 自然咨询 | 信息可能更碎，但主动性更高 |
如果这些 lead 都进同一个池子、走同一套规则，前端效率一定会被拉低。
VIPKID 当时怎么做
这一层系统做了几件很关键但不花哨的事：
- 投放靠 UTM 打标。
- 转介绍靠邀请链接或邀请码关联。
- 前面有 TMK 外呼筛选，不是所有注册都直接打给 CC。
- 转介绍和投放 lead 不进同一个分配池。
- 分配逻辑不是简单平均，而是带容量约束的加权轮询。
这一套设计的核心，不是“把线索记下来”，而是尽早把线索分层。
因为对高客单价业务来说，最贵的资源不是流量，而是后面的销售和班主任时间。
这里真正做对了什么
做对的不是某个字段，而是一个顺序：
先分清线索质量，再决定把谁交给谁。
这件事听起来很朴素，但很多 CRM 恰恰做反了，先把所有线索扔进去，再在销售侧消化。
VIPKID 当时至少避免了两个低级错误：
- 让高信任的转介绍 lead 和投放 lead 混在一起。
- 让高成本 CC 去处理本该在 TMK 就筛掉的低意向注册。
没解决什么
这一层我现在回头看，最典型的短板有两个。
第一，归因逻辑和业务承诺会冲突。
比如家长先点了广告，后来又拿朋友的邀请链接下单，如果系统严格按末次或某一套技术归因算，业务上就会出现“她明明是被朋友推荐来的，但优惠不给她”的问题。最后只能人工补偿。
第二，超级推荐人没有被系统化识别。
这点当时就存在，但没做深。系统能知道推荐关系，却没有把“谁是高价值推荐人”进一步抽出来做精细维护。这其实浪费了非常宝贵的一层增长资产。
通用原则
如果你的增长是人力驱动型，CRM 第一原则不是“收全所有 lead”，而是：
尽早区分线索质量，并让不同来源走不同路径。
二、转化支撑：把“当天联系”和体验课变成可执行动作
VIPKID 的转化不是看一个按钮转不转，而是看这条链路能不能尽快把家长送到体验课。
因为体验课不是功能试用，它是高客单价决策前的信任验证装置。
VIPKID 当时怎么做
这一层最关键的系统设计有三件：
- 销售能在 CRM 里直接预约体验课。
- CRM 和排课系统打通。
- CRM 和呼叫中心打通，外呼次数和通话时长自动记录。
还有一个非常现实但不那么“系统化”的事实：
“当天联系”是硬性 SLA，但它不是靠系统强制回收线索，而是靠 leader 管理压力盯出来的。
这点很值得写，因为它恰好说明了系统的边界。
这里真正做对了什么
这里的关键，不是“能打电话”，而是减少线索进入到体验课之间的断层。
如果销售还要在另一个系统里查档期、再去人工协调排课，那转化链路就天然变长。
VIPKID 当时把“销售跟进”和“体验课预约”放在一个动作链里，这是对的。
因为对于高信任产品，最怕的不是用户犹豫，而是用户在犹豫的时候系统还让他多等一步。
没解决什么
这层没解决的问题不是“系统没有记录”，而是：
系统能看见动作，不等于系统能创造执行意愿。
电话记录自动化是必要的，但它只能告诉你“有没有打”，不能告诉你“打得有没有用”。
这就是为什么通时通次不能被当成业务指标，它只是动作指标。
我现在回头看，会更明确地区分两类东西：
| 类型 | 例子 |
|---|---|
| 动作指标 | 电话量、通话时长、回访次数 |
| 链路指标 | 有效触达率、预约率、体验课出席率、体验课后转化率 |
动作指标的价值，是解释链路指标为什么变化；它本身不是增长结果。
通用原则
高信任产品的转化系统，最重要的不是记下成交，而是：
尽量缩短从“有兴趣”到“完成第一次验证体验”的时间。
三、交接支撑：销售签单不是结束，而是风险开始转移
在 VIPKID 这种业务里，销售签单不是闭环，它只是下一轮风险的开始。
因为家长买单之后，真正长期承接体验的是班主任和教学系统。
VIPKID 当时怎么做
系统层做了几件事：
- 付费后自动分配班主任。
- 班主任能看到基础信息、销售记录、备注、试听课回放、定级推荐和家长要求。
- 交接不需要人工审核，系统直接触发。
这套设计提高了效率。因为一旦订单确认，就不能再让用户等一个“人工交接”流程。
这里真正做对了什么
做对的地方是：信息至少是可见的。
很多组织的问题不是人不负责，而是后一个角色根本不知道前一个角色对客户说过什么。
VIPKID 当时至少把几个关键上下文接过去了：
- 这个家庭为什么来。
- 孩子大概什么水平。
- 试听课发生了什么。
- 家长提出过什么要求。
这让班主任不是从零开始。
没解决什么
真正大的坑在这里：
系统解决了“信息可见”，但没解决“信息真实性”。
销售有没有把过度承诺写进记录？通常不会。
班主任最后很多时候只能去听录音，或者在后续服务里慢慢发现问题。
这意味着交接系统有个天然盲区：
| 系统能解决 | 系统没解决 |
|---|---|
| 备注可见 | 备注是否完整 |
| 试听回放可见 | 销售是否过度包装 |
| 定级建议可见 | 销售承诺和真实教学是否一致 |
这也是为什么很多续费问题，根子其实埋在销售阶段。
通用原则
交接系统真正重要的，不是“把客户分给下一人”，而是：
让后一个角色尽快知道前一个角色有没有埋雷。
四、留存与续费支撑：系统记了结果，但没真正管理过程
如果说前面几层是在解决“怎么成交”，这一层解决的是“怎么持续”。
这也是我回头看，VIPKID 最值得复盘的一层。
VIPKID 当时怎么做
这里系统已经有一些不错的基础：
- 课程临近到期时，CRM 自动提醒班主任。
- 教学系统会把每堂课的回放和课堂报告推送到 CRM。
- 到了 3 节课节点，系统会强提醒，班主任必须回访，并提及升级。
这三件事背后的思路是对的：
把“学习发生了什么”变成班主任可操作的信息。
这里真正做对了什么
我认为最有价值的不是“到期提醒”，而是教学系统到 CRM 的自动推送。
因为课包业务有一个天然问题：
卖出课包不代表用户在真实使用，也不代表家长感知到价值。
如果教学结果回不到 CRM，后面的服务和续费动作就只能靠感觉。
另外，3 节课节点被固化到系统里，也很重要。
这相当于把“经验上什么时候最值得介入”变成了明确的任务触发，而不是靠班主任记忆。
没解决什么
但这里也有一个非常明显的缺口：
系统在记录续费结果，却没有真正管理续费过程。
也就是说，它能告诉你“有没有续上”，但不太能告诉你：
- 是什么时候开始推进续费的。
- 中间卡在哪一步。
- 哪类用户高风险。
- 哪些班主任过程做得好，但结果运气差。
这就是为什么我后来更倾向于把这层理解成“增长系统还没完全做完”。
对这类业务，更合理的北极星应该不是新签收入，而是：
健康在读收入
= 有效在读学员数
× 人均课时消耗
× 课时单价
× 续费率一旦用这个视角看，续费就不是一个订单动作，而是一条过程链路。
通用原则
对续费型业务来说，如果系统只记订单结果，不记过程，那它更像财务系统，而不是增长系统。
五、转介绍闭环：把信任传播做成系统动作
VIPKID 的转介绍不是可有可无的活动模块，它是增长引擎的一部分。
所以它不能只靠班主任口头提醒，必须系统化。
VIPKID 当时怎么做
这层最成熟：
- 海报在 App 端生成。
- 邀请链接自动关联推荐人。
- 付费后奖励课时自动发放。
- 班主任只负责提醒，链路本身尽量自动化。
这里真正做对了什么
这层做对的核心不是“奖励发得快”，而是：
把信任传播从人工对账，变成系统闭环。
如果推荐关系、触发条件、奖励发放都靠人工处理，增长飞轮永远起不来。
而 VIPKID 这类业务里，班主任不应该成为转介绍流程的操作员。班主任的作用更适合停留在“提醒和触发”，真正的关联、归因和奖励必须自动跑。
没解决什么
这层最大短板不是链路自动化，而是关系经营没有进一步系统化。
也就是说，系统能识别“谁推荐了谁”，却没有进一步识别：
- 谁是超级推荐人。
- 谁的推荐转化质量最好。
- 哪类推荐人值得重点维护。
如果转介绍是核心引擎，这其实是一个没被吃干净的红利。
通用原则
如果转介绍是核心增长杠杆，就不要把它当成一次活动，而要把它当成一张关系网络来设计。
系统化边界：CRM 能自动化什么，不能自动化什么
写到这里，其实结论已经开始清楚了。
不是所有问题都该塞给系统，也不是所有问题都该靠管理。
我更愿意这样划分：
适合系统化的
| 适合系统化的环节 | 原因 |
|---|---|
| lead 打标与分流 | 规则清晰、高频重复 |
| 体验课预约 | 跨系统协同，人工会拖慢链路 |
| 教学报告回流 | 数据标准化程度高 |
| 推荐关系和奖励发放 | 条件明确，适合自动触发 |
| 关键节点提醒 | 事件触发清楚，适合固化 |
不适合只靠系统化的
| 不适合只靠系统化的环节 | 原因 |
|---|---|
| 当天联系是否有效 | 系统能提醒，不能替代执行意愿 |
| 销售是否过度承诺 | 能记录，但很难自动判断 |
| 班主任服务质量 | 系统能记录结果，不能创造信任 |
| 续费时机判断 | 很多时候仍依赖经验和家长状态 |
本来应该更系统化，但当时没做好的
| 缺口 | 为什么危险 |
|---|---|
| 续费过程管理 | 只能看结果，不能看过程卡点 |
| 超级推荐人识别 | 高价值关系资产没有被运营 |
| 归因逻辑和业务承诺统一 | 技术归因和业务体验发生冲突 |
这也是我现在最认可的一句话：
CRM 最擅长解决信息问题，不擅长解决人性问题。
系统能让问题暴露得更早，但不能替代人做出好的判断。
做得好的地方，和真正危险的缺口
如果一定要压缩成一张复盘表，我会这么写。
做得好的
| 做得好的地方 | 为什么重要 |
|---|---|
| TMK 前置过滤 | 保护了高成本销售资源 |
| CRM 直连体验课预约 | 缩短了转化链路 |
| 呼叫中心打通 | 让销售动作变得可见 |
| 教学系统 → CRM 自动推送 | 把课堂结果带回运营链路 |
| 转介绍链路自动化 | 让信任传播真正可规模化 |
| 3 节课节点固化 | 把经验型动作变成系统动作 |
| 班主任容量上限 | 承认服务能力本身就是增长约束 |
应该做但没做好的
| 缺口 | 为什么危险 |
|---|---|
| 续费漏斗/过程管理 | 系统只能看结果，不能过程优化 |
| 销售过度承诺防控 | 交接阶段的雷只能靠人工排查 |
| 归因逻辑和优惠承诺冲突 | 既伤体验，也伤推荐动力 |
| 超级推荐人识别和维护 | 核心增长资产没有被单独经营 |
如果今天让我给优先级，我会把后面四件事排成：
- 续费过程管理
- 销售过度承诺防控
- 超级推荐人识别
- 归因逻辑统一
因为前两项直接影响收入质量，后两项影响增长效率。
人力驱动型增长的 CRM 设计检查表
如果你的业务也像 VIPKID 一样，高客单价、高信任、重服务、买家用户分离，这张表比任何 CRM 术语更有用。
- 你的 lead 来源能不能被准确区分，而不是混成一个大池子？
- 不同来源的 lead，是否走不同分配逻辑？
- 从线索进入到第一次验证体验，中间有没有多余断层？
- 销售和后续服务之间，有没有结构化交接信息？
- 系统能不能记录“承诺”，还是只能记录“备注”？
- 教学/交付结果，能不能自动回流到运营中枢？
- 续费有没有过程管理，而不是只看最后下不下单？
- 你的关键行为节点，是否已经被固化成系统触发？
- 转介绍关系、奖励发放和归因是否自动闭环？
- 哪些问题应该系统化，哪些必须靠组织和管理来兜底？
如果这 10 个问题里有一半答不上来，那你的 CRM 更像“记录系统”，还不是“增长基础设施”。
最后：CRM 不是替代人，而是减少失真
我做完 VIPKID 这套系统之后，最大的感受不是“系统很重要”，而是：
人力驱动型增长，其实比轻产品增长更依赖系统。
因为轻产品出问题，很多时候是用户自己在产品里卡住；而人力驱动业务出问题，往往发生在角色之间：
- lead 信息断了。
- 销售承诺变形了。
- 体验课和主修课脱节了。
- 班主任接手时少了一句话。
- 教学结果没被运营层看到。
- 推荐关系最后靠人工对账。
这些问题单看都很小，但串起来就足够让整台引擎抖起来。
所以好的 CRM 不是替代人，而是减少失真：
- 让信息不要丢。
- 让责任不要漂。
- 让关键时机不要靠记忆。
- 让问题尽可能早暴露。
它能解决信息问题，解决不了人性问题。
但好的系统至少能让人性问题不至于藏太久，等到收入和流失一起爆的时候才被看见。