客户流失流程图（挽留行动到赢回）
客户流失流程图模板：风险信号、挽留行动、挽留结果判断、离场访谈、退出交接、赢回资格，以及流失分析的反馈循环。
什么是客户流失流程图（挽留行动到赢回）流程
这张图从续约健康检查结束的地方开始：一个账户触发了真实的风险信号，而不只是一次例行复核。触发因素是使用量低于基准、支持升级次数骤增，或账户自身发出的续约预警，客户成功团队会先调取该账户的使用与账单历史，再把信号当作真实的来处理。从这里开始，这张图追踪一个流失案例的全过程：指定挽留行动负责人、进行高管接触、给出与实际流失原因相匹配的挽留方案、客户做出留下还是离开的决定，以及在较艰难的一支：离场访谈、退出交接、赢回资格的判断，以及回馈到产品路线图与下一个风险账户挽留手册中的流失原因。
这是流失管理，不是续约周期，也不是退订的文书工作。判断账户一开始是否处于风险中的健康分复核、到期前90天的续约提案，以及自动续约条款，都属于客户续约流程，本图只在风险已经确认之后才从那里接手。而一旦客户的通知送达，详细的数据导出与权限注销清单、权益关闭，以及末期账单的具体机制，就是它们自己的行政性退订流程；本图在移交之前只确认访问权限截止日期与末期账单，这是刻意为之，为的是不让流失中情感上和商业上都更重要的那一半——挽留行动、原因、赢回判断——被埋在一份系统步骤清单里。保持这条边界清晰，正是防止一次流失复核变成一队退出交接工单的关键。
三个判断撑起这套流程。「风险是否确认？」是一道真实的关卡，不是走过场：平静的一个月不等于流失，观察名单这条回路存在的意义，就是不让挽留行动负责人的时间耗在噪声上。「客户是否挽留成功？」是整张图围绕建立的分岔点，它被放在客户泳道而不是客户经理的泳道，因为真正的结果是客户的决定，而不是那份方案。「是否符合赢回资格？」被刻意放在退出交接之后而不是之前：资格要在案例关闭之后，依据流失原因与账户状态来判断，而不是在挽留行动进行得如火如荼时仓促决定——那恰恰是最容易判得过于慷慨或过于苛刻的时刻。
本流程图涵盖的内容
本模板包含
- 六条泳道——客户成功、客户经理、客户、客服、财务 / 计费与产品 / 管理层——横跨六个阶段：风险信号、挽留行动、挽留结果、退出交接、赢回，以及分析与反馈
- 顶端「风险是否确认？」这一判断带有真实的回路：不明确的信号会被加入观察名单并重新复核，而不是仅凭一个数据点就被放弃或升级
- 挽留行动不止于一通道歉电话：具名的挽留行动负责人、高管接触，以及「方案是否超出标准权限？」这一判断，会在客户经理向客户提出任何方案之前，先把更大额的折扣或额度送去财务审批
- 「客户是否挽留成功？」这一判断放在客户泳道而不是销售一方，把整张图清晰地一分为二：挽留成功即结案，仍然流失则开启离场访谈
- 离场访谈与退出交接被当作一次轻量的移交而不是一份清单来处理：记录下「流失原因」，确认访问权限截止日期与末期账单，再把账户作为单独一步移交给账户注销清单
- 「是否符合赢回资格？」这一判断依据原因与账户状态而不是资历来判定，赢回活动受冷却期约束，「流失是否由产品缺口导致？」这一分支则把发现导向产品路线图，或者送回挽留行动手册
何时使用本模板
- 你们正在搭建客户成功手册，需要用一幅图看清流失风险从信号、挽留行动到退出交接由谁负责
- 各个客户经理的挽留行动做法不一致，你们需要把挽留方案的审批与高管接触这一步明确写出来
- 已流失的账户完成了退出交接却从未被分析，导致同一个本可避免的原因一个季度后又出现
- 你们正在判断一个已流失的账户是否适合纳入赢回活动，希望把标准和冷却期写明确，而不是全凭记忆
- 管理层在向董事会汇报留存情况之前，要求提供一份成文的流失流程，挽留行动、退出交接与分析这几步需要以同一条流程呈现
运作方式
把泳道改成你们的角色
用你们组织中真正存在的角色替换客户成功、客户经理、客户、客服、财务 / 计费与产品 / 管理层。小团队常常把客户成功与客户经理合并成同一位挽留行动负责人：这样做，而不要画一次从不会发生的交接。
定义什么算作已确认的风险信号
写明哪些使用指标、客服信号或通知强到足以开启一个案例，以及谁有权把账户加入观察名单而不是开案。标准含糊，正是挽留行动负责人的时间被耗在追逐噪声而不是真实账户上的原因。
设定挽留方案的权限门槛
决定客户经理不经审批可以提供什么、什么需要财务批准，用你们自己的说法，而不是照搬另一个团队折扣政策里的一个百分比。写清楚对一笔小交易与对一个战略账户来说，财务具体指谁。
商定流失原因如何被记录
决定谁来做离场访谈、一份完整的原因记录必须包含什么、存放在哪里。一个六个月后没人能找到的原因，无论访谈本身做得多好，都无法供给分析这一步。
写出你们自己的赢回资格规则
写明哪些流失原因和账户状态使一个账户有资格参加未来的活动、哪些没有，并设定你们自己的冷却期长度，而不是沿用图上的占位周期。指定谁负责赢回名单，以免它悄悄停摆。
决定流失发现最终去向哪里
商定谁以什么频率复核汇总后的流失原因，以及一个指向产品缺口的发现，和一个指向挽留行动手册本身的发现，各自该如何处理。没有负责人的复核，只会产出一页没人依据它行动的幻灯片。
拿两个真实案例对照走一遍
找一个被挽留成功和一个流失的账户，把两者都放到图上走一遍。凡是大家凭记忆描述、却没有画出来的步骤，或者画了却在实际中常被跳过的步骤，都是发布这套流程之前值得修正的发现。
常见问题
客户流失流程包含哪些步骤？
流失案例在账户触发真实的风险信号时开启：使用量下降、一连串客服升级，或早期的续约预警。客户成功团队调取该账户的使用与账单历史，确认风险是真实的，而不只是平静的一个月——后者会被加入观察名单并重新复核。已确认的案例会指定挽留行动负责人、进行高管接触，并给出与实际流失原因相匹配的挽留方案，其中较大额的折扣先送财务审批。客户的决定就是分岔点：挽留成功即以留存结案，仍然流失则触发正式的流失通知、记录原因的离场访谈、确认访问权限截止日期与末期账单，以及移交至账户注销清单。随后案例会经过赢回资格判断、面向合格账户且受冷却期约束的赢回活动，以及在结案前把原因对照产品缺口与挽留行动手册的最后一步。
什么是挽留行动，它和打折有什么不同？
挽留行动是围绕一个风险账户展开的整套挽留努力，而不只是最后那份方案：一位具名的负责人、让客户听到更高层声音的高管接触，以及一份理应匹配账户实际流失原因的计划。折扣只是这份计划里的一种可能手段，而且常常是用错的那一种。一个因为竞品推出了某项功能而流失的账户，靠打折解决不了；它需要的是路线图承诺，或者一份展示如何弥补差距的成功计划。一个因为价格而流失的账户，倒确实可能需要折扣。把每一次挽留行动都变成一场折扣谈判，正是客户成功团队看起来像个议价柜台而不是关系团队的原因，也正是在训练客户用离开来要挟换取更好价格的原因。
如何判断一个已流失的账户是否适合赢回活动？
依据流失原因与账户离开时的状态来判断，而不是依据它做客户多久，或客户经理对这次损失的感受。因竞品功能而流失、且差距仍未弥补的账户，或者带着欠款或处于纠纷中离开的账户，通常在那个具体条件改变之前，都是较差的赢回候选。条件良好但对价格敏感而流失的账户，或者因内部推动者离职而流失的账户，一旦过了一段时间，往往是真正的候选。把规则写下来并始终如一地执行，因为在账户刚流失的那一刻判断资格，容易因为愧疚而过于慷慨，也容易因为对挽留行动过程的沮丧而过于苛刻。活动开始前冷却期该有多长，是你们团队自己要定的政策，而不是一条固定规则。
账户都已经流失了，为什么流失分析还重要？
一个流失的账户是一次损失；多个账户中重复出现的模式则是一项发现，而汇总这一步存在的全部意义，就是把两者区分开来。如果同一个原因反复出现，解决办法通常不是再来一次挽留行动，而是改变产品本身，或者改变挽留行动手册本身——这正是「流失是否由产品缺口导致？」这一判断所指向的方向。跳过这一步，正是一个组织多年重复同一套失败的挽留行动的原因：每一次都把当下的账户当作孤立个案，而不是管理层从未在同一处看到过的某个模式的第五个案例。离场访谈留下的记录，正是让这一切在日后成为可能的东西，这也是为什么在当下记录一个具体原因，其重要性远超当时的感觉。
流失流程应该由谁负责：客户成功、销售，还是产品？
在大多数组织里，客户成功从头到尾负责这套流程，因为他们离账户最近，也是那段必须撑过艰难对话的关系的所有者。挽留行动本身通常会拉入客户经理，因为客户往往对比日常联系人更高层的人有不同的反应，而超出标准折扣权限的一切审批都由财务负责。产品不负责这套流程，但必须是流失原因发现的真正接收方，而不只是图上的一条泳道，否则汇总这一步就会变成没人依据它行动的报告。无论你们在自己组织里怎么划分，都要为案例从开启到结案指定唯一的负责人；没有唯一负责人的流失案例，正是那种原因被记录得很差、赢回机会被彻底错过的案例。