流失挽救 playbook

触发条件

Agent 产品的流失早期信号比 SaaS 早 2-3 周显现，关键差异是：任务完成率下降通常先于登录频次下降。一个一天用 5 次但每次失败的客户，比一个一周用 1 次但全部成功的客户更危险。

自动化监控以下信号，命中任一即触发流程：

信号	阈值	严重度
任务完成率下降	14 天内 > 15 pp 跌幅	高
HITL 介入率上升	14 天内 > 10 pp 升幅	高
7 日回访率	跌至 < 30%	中-高
月活 workflow 数	下降 ≥ 2	中
主要使用者 30 天未提交任务	命中即触发	中
Token 月用量	下降 > 40%	中

高严重度信号：CSM 在 48 小时内接触；中严重度：1 周内接触。

角色与责任

角色	主要责任
CSM	Owner；接触客户、识别根因、协调内部介入
工程	根因是产品质量（完成率下降、HITL 飙升）时介入排查
产品	根因是 workflow 错配时，调整推荐、重新激活
销售	客户提到合同 / 价格问题时介入；非合同问题不参与

介入时间线

Day 0-3：信号确认与根因分析

CSM：

1. 24 小时内核对自动告警，过滤误报（客户 PTO、产品下线维护期等）
2. 分析过去 30 天的任务级日志：完成率、错误类型、HITL 触发原因
3. 把根因划入三类：
   • 产品质量问题——完成率下降跟特定 workflow / 任务类型相关 → 升级工程
   • 使用问题——用户尝试了超出 agent 能力的任务，或 workflow 配置错 → CSM 教育 / 重新激活
   • 业务变化——客户业务调整、负责人离职、合同问题 → 销售介入

Day 4-7：定向介入

按根因执行。

产品质量问题：

1. 工程 24 小时内分析定位（参考 incident-response）
2. CSM 给客户主联系人主动通报事故性质（不等客户来问），告知预计修复时间
3. 修复后 CSM 二次接触，确认客户感知

使用问题：

1. CSM 召集 1 对 1 沟通，理解客户原始期望与实际使用差距
2. 推荐 2-3 个适配的 workflow / 任务类型
3. 提供再激活样例：3-5 个高完成率首任务

业务变化：

1. 销售接触客户主联系人 / 新负责人
2. 评估合同灵活性：缩规模、降 tier、暂停而非取消
3. 不要轻易降价——降价不解决根因，且为下次谈判设了低锚点

Day 8-14：跟踪恢复

CSM：

• 监测同样的 6 个信号是否回升
• 任务完成率回到流失前水平 ≥ 80% 视为初步恢复
• 7 日回访率 > 50% 视为习惯重建

Day 30：判定结果

CSM 与销售联合 review：

• 挽救成功——信号回升、客户主动表达继续使用意愿。归档案例
• 稳定但低活——客户继续使用但量级减半。接受现状、列为低优先级账户
• 流失确认——客户停付 / 合同到期不续。完成离职访谈、归档失败原因

关键不要做的事

• 不要靠”折扣”挽救——一次性现金流换走客户未来期望的折扣权，长期账损失大于短期收益；agent 产品的成本结构使得折扣价对供应方的毛利伤害远大于 SaaS
• 不要在确认根因之前推荐新 workflow——客户已经体验质量下降，再推没用过的 workflow 会被解读为”还要我再投入”
• 不要让支持代替 CSM 处理流失——支持解决具体工单，CSM 才能看到模式；混淆角色会让流失被记为”工单已关闭”
• 不要在客户离职访谈中辩护——目标是收集真实原因供产品迭代，不是赢辩论

度量指标

按季度跟踪：

• 早期信号触发量 vs 实际流失数：理想比例 3:1——不是每次触发都是真流失，但应该能覆盖大多数真流失
• 挽救成功率：触发后 30 天内信号回升的比例（健康基线 40-60%）
• 挽救时长中位数：信号触发到恢复的天数
• 流失原因分布：按根因分类，定期 review 排前三的、反推产品 / 销售流程修改

与其他章节的衔接

• 流失早期信号的具体指标：metrics/overview
• 产品质量问题升级路径：incident-response
• Agent 完成率下降的客户 ROI 影响：economics/controls-and-roi
• 内部支持工单与流失的早期关联：support-runbook