流失挽救 playbook

触发条件

Agent 产品的流失风险常常先出现在任务质量里，再出现在登录频次里。一个一天提交多次但反复失败的客户，可能比一个低频但每次成功的客户更危险。

自动化监控以下信号。阈值是起点，实际应按客户规模、任务类型和历史波动校准：

信号说明严重度
任务完成率明显下降同一客户、同一 workflow 的近期成功率低于自身历史水平高
HITL 介入率上升高风险动作、人工确认或人工修正变多高
回访率下降首次成功后不再回来，或稳定用户突然断档中-高
活跃 workflow 数下降用户只保留最基础用法，不再尝试相邻任务中
主要使用者停用champion 离职、转岗或停止提交任务中
成本或账单异议增加客户开始质疑价值和价格是否匹配中

高严重度信号应快速确认并接触客户；中严重度信号可以先观察短周期趋势，再决定是否人工介入。

角色与责任

角色主要责任
CSMOwner；接触客户、识别根因、协调内部介入
工程根因是产品质量、工具失败、模型路由或系统稳定性时介入
产品根因是 workflow 错配、引导不足或推荐错误时介入
销售客户明确提出合同、预算或价格问题时介入

介入时间线

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

CSM 先确认告警是否真实，再看过去一段时间的任务日志、错误类型、HITL 原因、用户反馈和账单变化。

根因通常分四类：

  • 产品质量问题：完成率下降集中在某个 workflow、工具或模型版本。
  • 使用方式问题：用户把 agent 用在当前能力不稳定的任务上，或输入/权限配置不对。
  • 价值解释问题：任务成功了，但客户看不清节省了什么、为什么值得付费。
  • 组织变化问题：负责人更换、预算收紧、团队流程改变。

Day 4-7：定向介入

按根因选择动作：

  • 产品质量问题：工程排查，CSM 主动说明影响范围和修复路径。
  • 使用方式问题：CSM 重新推荐适配 workflow，并给出可复制的示例任务。
  • 价值解释问题：用客户自己的任务数据复盘节省时间、完成质量和人工复核成本。
  • 组织变化问题：销售与 CSM 一起重新确认预算、采购周期和内部 champion。

不要在确认根因之前推新 workflow。客户已经感到价值下降时，新的任务建议很容易被理解成额外负担。

Day 8-14：观察恢复

继续监控触发信号是否改善。恢复不只看登录，也要看：

  • 原问题 workflow 是否恢复稳定；
  • 用户是否重新提交相邻任务；
  • 人工复核或支持工单是否下降；
  • 客户是否认可新的价值解释。

Day 30：归档结果

将结果归入三类：

  • 挽救成功：质量和使用信号恢复，客户明确继续使用。
  • 稳定但低活：客户保留产品，但使用范围缩小，后续降低运营优先级。
  • 流失确认：客户停付或不续约，完成离职访谈并归档根因。

常见误区

  • 靠折扣挽救：折扣只能缓解价格异议，不能修复质量、任务错配或组织变化；如果单位经济本来紧张，还会放大毛利问题。
  • 把质量问题当培训问题：用户可能不会再给第二次机会。
  • 让支持代替 CSM 判断流失：支持解决工单，CSM 才能看到客户关系和价值变化。
  • 在离职访谈中辩护：目标是获得真实原因，不是赢下争论。

度量指标

按季度跟踪：

  • 早期信号覆盖率：告警是否覆盖真实流失，同时没有制造过多噪音。
  • 挽救成功率：触发后 30 天内信号回升的比例。
  • 挽救时长中位数：信号触发到恢复的天数。
  • 流失原因分布：按产品、使用、价值、组织、价格分类，反推产品和运营改进。

与其他章节的衔接

这页有帮助吗？
在 GitHub 编辑