运营手册

Agent 产品运营 playbook 集合——客户成功、上线、扩张、流失挽救、内部支持。每篇是给具体角色在具体触发条件下使用的标准操作。

任务完成率下降比登录频次下降早 2-3 周

Agent 产品的流失早期信号比 SaaS 早 2-3 周显现——任务完成率下降通常先于登录频次下降。如果运营按 SaaS 旧习惯只监控登录频次，看见信号时客户已经准备离开。

因此 agent 产品的 playbook 在三处必须重做：

  • 触发条件按 agent 特定信号（任务完成率、HITL 介入率、workflow 数）而非通用使用量
  • 介入动作包含产品端调整（推荐合适任务、调整 tier）而非纯销售对话
  • 度量指标按 metrics/overview 的三层框架对齐

五份核心 playbook

客户上线 playbook

从合同签订到首次成功任务的 30 天里程碑。最关键的 playbook——agent 产品的”激活质量”决定后续留存。详见 onboarding。

扩张 playbook

已激活客户向更多 seats、workflows、capacity 扩张的触发条件与流程。基于 growth/expansion 的三种扩张路径设计具体操作步骤。详见 expansion。

流失挽救 playbook

使用频次下降的早期信号识别与介入策略。Agent 产品的流失信号比 SaaS 早 2-3 周显现——任务完成率下降通常先于登录频次下降。详见 churn-save。

内部支持 runbook

典型支持工单的处理流程；何时升级至工程。Agent 产品的支持工单分类包含 SaaS 没有的类型：“agent 输出错误”、“任务卡住”、“账单远高于预期”。详见 support-runbook。

事故响应 playbook

Agent 系统级故障（推理失败、token 耗尽、上游模型不可用）的对外沟通模板。详见 incident-response。

写作约定

每份 playbook 应包含五个固定部分：

  1. 触发条件——什么情况下启用此 playbook（具体到指标阈值，不写”用户活跃度下降”这种模糊判断）
  2. 角色与责任——谁执行哪一步（客户成功、销售、支持、工程各自的边界）
  3. 操作步骤——按时间顺序的动作清单，每步包含完成判定
  4. 升级路径——什么情况下升级到上一层（销售经理、CS lead、工程负责人）
  5. 度量指标——这份 playbook 执行后用什么指标判断成功

Playbook 不是案例报告。每份是给一线运营在具体触发条件下直接执行的操作手册，写法上偏 SOP 不偏 narrative。

与其他章节的衔接

这页有帮助吗？
在 GitHub 编辑