客户退订流程图（从申请到账户关闭）
客户退订流程图：核对合同条款与通知期，先记录退订原因再谈挽留，挽留方案的权限上限，末期账单、数据导出、权限回收与流失归因。
什么是客户退订流程图（从申请到账户关闭）流程
退订是大多数订阅制企业从未写下来的那个流程，所以它也是投诉最多的那一个。申请从取消按钮以外的地方进来，压上四天，然后由随手接过它的人用一个自己临时想出来的折扣去回复。没有人在方案摆上桌面之前记录客户为什么要走，等到问出口时，答案永远是价格。通知期是在客户对末期账单提出异议的那一刻才被第一次读到。申请到达的当天下午访问权限就被关掉，哪怕这个账户的服务费已经付到六周之后——于是一个本来平静离开的客户，现在开了工单，还在公开渠道有话要说。最后流失被记成一个数字，把主动选择离开的人和银行卡过期的人混在一起。这些都不是判断失误。每一件都是一个从来没有指派给任何人的步骤，出现在一个靠习惯而不是靠制度存在的流程里。
本图覆盖的是一份正在生效的订阅或服务合同的退订，从收到退订意向的那一刻，到流失完成归因、账户或进入赢回队列、或被屏蔽后续联系为止。它不是退款流程：单笔交易的退款、时效窗口、善意补偿的审批与拒付争议属于 /zh/templates/客户退款流程。本图只在末尾按比例退款这一步调用那份工作。它也不是投诉或升级：一个生气但并不打算离开的客户属于 /zh/templates/客户投诉处理流程。需要向上传递时，去 /zh/templates/客户投诉升级流程。而一次已经开了工单的服务故障属于 /zh/templates/客户支持升级流程。它也不是在到期之前从容做出的续约决定，那是 /zh/templates/合同续签流程。那份图由到期提醒触发，而不是由一份正在处理的申请触发，并且是站在谈判桌另一侧画的——在那里，你是那个决定要不要继续付钱的客户。账户关闭之后仍未收回的欠款交给 /zh/templates/应收账款流程。而本图是 /zh/templates/客户导入流程 的另一端：在那里开通的账号、集成和许可，正是在这里被逐一收回的。
多数写下来的退订程序留作默认的三件事，在这里被画成了决策。“是否允许挽留？”在账户审查阶段就被回答，位于挽留方案阶梯之前而不是之中，一次为限的规则也住在这里：已经用挽留方案留下来过一次的账户、正处于计费争议之中的账户，以及明确表示不希望再被推销的客户，都直接走向通知环节。“让步是否在专员权限内？”把专员可以自行给出的东西和需要主管批准的东西分开，让挽留方案阶梯有一个写下来的上限，而不是一种心情。而“是否已到生效日期？”是一道真实的门槛，它后面挂着一个等待循环，因为这个流程里最伤人的习惯，就是在申请当天回收权限。非自愿的那条路也画了出来：“主动退订还是欠费？”把一次扣款失败分流到它自己的催缴路径，最终要么恢复账户，要么汇入同一条通知与退出主干，这样欠费就不会被当成客户主动离开来上报。
本流程图涵盖的内容
本模板包含
- 六条泳道——客户、挽留专员、挽留主管、计费、服务运营与收入运营——铺在六个阶段上：受理、账户审查、挽留、通知与结算、退出交接与流失分析。
- 来自任何渠道的受理，并在“主动退订还是欠费？”处分流：扣款失败走自己的催缴与停服循环，最终要么到达“账户恢复，不计入流失”，要么在书面确认那一步汇回主流程。
- 谈判之前先做账户审查：“登记申请并调取合同”以确认最短服务期、通知期与自动续订，然后“按分类目录记录退订原因”，再经过“是否允许挽留？”这道门槛，它执行每个账户只挽留一次的规则。
- 一条带上限的挽留泳道：“按阶梯提出挽留方案”，一道“让步是否在专员权限内？”的检查把超出部分路由给挽留主管、再返回修订后的方案，以及一个客户决策，它要么终止于“变更已执行并约定回访日期”，要么继续向前。
- 通知与结算：“书面确认通知期与生效日期”、末期账单与按比例分摊的计算，以及一个三分支的“生效日应如何结算？”，涵盖应退款、应收提前解约费用，或两不相欠。
- 退出交接与关闭：一个“是否已到生效日期？”的循环，在日期到来之前维持访问权限并保留数据导出通道，“回收访问权限并设定删除日期”，退订调研，在 CRM 中的流失归因，以及一个“是否可纳入赢回名单？”的分叉——进入赢回队列，或关闭并屏蔽后续联系。
何时使用本模板
- 你们要写一份退订政策或流失应对手册，需要用一张图说清楚谁接收申请、谁可以给折扣、谁出账单、谁关闭服务。
- 你们的流失只有一个总数，没有人说得清其中多少是客户主动离开，多少只是代扣失效或银行卡过期。
- 同类账户被不同的专员用不同的折扣挽留，而对于专员在不经主管批准时能给出多少，并没有写下来的上限。
- 客户总说自己比你们记录的时间更早提出了退订，而通知期与生效日期是一单一议地争，而不是书面确认下来的。
- 你们正在配置计费、CRM 或权限开通系统，希望在自动化之前先把挽留、计费与服务运营之间的交接谈定。
运作方式
把泳道改成你们自己的团队
把客户、挽留专员、挽留主管、计费、服务运营和收入运营换成你们真实存在的职能。小团队通常把挽留专员并入客服，把主管那条泳道交给对收入负责的那个人；纯自助式的产品可能根本没有挽留席位，这时挽留方案阶梯就变成退订流程里的几个页面。宁可把一条泳道并掉，也不要让它空着。但客户泳道请保留原样：它承载两个方框——提出申请，以及对挽留方案的答复——在这之后的一切都是对账户做的，而不是和客户一起做的。
先写好退订原因分类目录，再去碰挽留方案
“按分类目录记录退订原因”在这份清单存在、并且短到可以直接选之前，是没有价值的。八到十二个编码通常就够了：价格、缺少功能、服务或稳定性不佳、使用率低、预算削减、项目或合同结束、改为自研、转向某个具名竞品、企业停业或被并购。再加一个自由填写框，并把编码设为工单推进之前的必填项。然后定下谁来复盘分布、多久复盘一次，因为一份没有人回头去读的分类目录，最终会漂移到下拉框里的第一个选项上。
搭好挽留方案阶梯，并给它一个上限
按它们对你们的成本从低到高排列梯级，而不是按感觉：暂停或降级套餐，延长合同期换取更低单价，服务抵扣或增加权益，最后才是直接的价格折扣。在“让步是否在专员权限内？”旁边，把专员的上限写成年度合同额的一个百分比和一个最长期限，并指明每一档之上由谁批准。把那些让“是否允许挽留？”得出否定答案的排除项记录下来，然后按原因编码去度量每一档梯级真正留住了什么，让阶梯的顺序由证据决定，而不是由专员最容易给出的那个让步决定。
定下通知期规则和生效日期
决定什么启动通知期的计时——是收到退订意向的日期，而不是工单被创建的日期——以及这段期限按自然月计算，还是算到下一个计费日。写明在自动续订截止日之后才提出退订会怎么处理，因为那正是产生争议的那类情形。然后固定“书面确认通知期与生效日期”的内容：各个日期、关闭之前的服务标准、预计的末期金额、数据导出的途径和删除日期。面向个人消费者时，消费者权益保护方面的强制性规定可能优先于合同里更长的通知期，请先核对。
设定权限回收与数据留存的时钟
把“回收访问权限并设定删除日期”变成一份清单，覆盖用户账号、API 密钥与令牌、集成、单点登录授权、共享内容、邮件列表，以及随服务发放的任何硬件或许可。确定账户关闭之后保留什么、依据什么合法性基础、保留多久——计费与发票记录通常要为税务和会计档案的要求继续保留一段时间，个人信息则不应如此——并把删除排成计划任务，而不是留给几个月之后的一次人工决定。写明由谁确认已经执行，以及这条确认记录在哪里。
约定流失口径，然后走一遍并发布
在任何人动手做报表之前，先定好主动流失与非自愿流失如何计数、一次退订归属到哪个日期、降级或暂停如何处理。写清楚“是否可纳入赢回名单？”背后的屏蔽规则，以及再次联系一位老客户之前的最短静默期。然后带着定稿的图与一位挽留专员、一位计费同事和负责权限开通的人一起走一遍，按他们实际的做法而不是政策上的写法改正，再发布该版本并保留此前的版本，让日后打开它的人知道自己看的是哪一版。
常见问题
客户退订流程包含哪些步骤？
无论申请从哪个渠道进来都先接收下来，并带时间戳登记；调取合同，确认最短服务期、通知期和自动续订日期；在提出任何挽留方案之前，按固定的分类目录记录原因；判断这个账户是否允许挽留；从挽留方案阶梯里提出一次方案，让步超出专员权限时升级给主管；要么执行谈定的变更并约定回访日期，要么书面确认通知期与生效日期；计算并结清末期账单，结果是按比例退款、提前解约费用，或两不相欠；在生效日期到来之前维持访问权限并保留数据导出通道；到期再回收权限，而不是在申请当天回收，同时设定删除日期；发送退订调研；在 CRM 中完成流失归因并上报；最后决定这个账户是可以纳入赢回名单，还是应当屏蔽后续联系。顺序比清单更重要：原因记录在方案之前，权限回收在生效日期之后，这两点才是防止流程出错的地方。
本页与客户退款流程图有什么不同？
退款流程结算的是一笔付款。它要问这笔申请是否落在退款政策和时效窗口之内、主管是否会批准一次善意例外、原始付款是否已经完成清算且尚未退过款、是否有一笔拒付正在并行处理——它在钱回到客户手上时结束。那片地面在 /zh/templates/客户退款流程。而退订流程结束的是一段关系，钱只是其中一条腿。本图处理的是合同通知期、最短服务期与自动续订、挽留方案以及谁有权批准它、生效日期、权限回收、数据导出与删除、退订调研，以及流失如何归因和上报。两者只在一个点上相交：“生效日应如何结算？”可能得出应退款，而把这笔钱退出去是退款那边的工作。如果你们要判断的是一笔交易该不该退钱，请用退款模板；如果你们要结束的是一份订阅或一份合同，请用这一份，并让它在那一个步骤上调用退款流程图。
是不是每个提出退订的客户都要挽留一次？
不是，而且本图把这个问题放在方案之前，而不是之后。“是否允许挽留？”排除了几类：在上一次退订时已经接受过挽留方案的账户、明确表示不希望再被推销的客户、正处于计费或服务争议之中的账户（此时一个折扣会被读成和解条件），以及已经停业、被并购或预算彻底没有了的企业。对这些情形提方案，既浪费专员的时间，也惹恼那些早已做完决定的人。一次为限这条规则背后的商业理由更简单：仅靠价格留下来的客户，往往在一个合同期之后带着那个新的、更低的数字回到同一场谈判，所以一家对每次退订都打折的公司并不是在留住收入，而是在一个账户一个账户地给自己的存量重新定价。按原因编码去看挽留成功率和平均让步幅度，这个规律很快就会显形。
退订的客户应该在什么时候失去服务访问权限？
在生效日期，也就是已付费周期的结束日或合同通知期的结束日，而不是提交申请的那一天。本图把这一点画成了一个决策，“是否已到生效日期？”，它后面挂着一个等待循环，在日期到来之前保持账户可用、保持数据导出通道畅通。提前切断访问是这个流程里最常见的失误，而且它的代价远远超过省下的那点服务：客户已经为这段时间付过钱，通常还需要把数据取出来，于是一次干净的离开变成了一张工单、一次拒付或一条公开差评。例外情形很窄，应当单独写明——催缴走完全程仍未收回欠款、违反服务条款、欺诈——并且应当由有权做这个决定的人来定，而不是由恰好处理这次退订的人来定。
主动流失和非自愿流失有什么区别？
主动流失是客户决定离开。非自愿流失是账户因为一笔付款失败且始终没有收回而关闭——银行卡过期或换卡、免密代扣协议失效或余额不足、一次被拒绝的交易，或者一张发票丢在了对方的采购到付款（P2P）流程里。它们在一个流失总数里看起来一模一样，底下却毫无共同之处。主动流失要用产品、服务和定价的工作去回应；非自愿流失要用支付链路的工作去回应，比如支付方式的自动更新、更合适的重试节奏，以及真的有人会读的催缴通知，而其中可挽回的比例高得出人意料。这正是本图在受理阶段用“主动退订还是欠费？”把两者分开、并给欠费那条路自己的催缴与停服循环的原因——它要么以恢复账户、不计入流失结束，要么汇入同一条通知与退出主干。在 CRM 里分开归因、分开上报，否则可挽回的那一半会一直藏在平均数里。
此流程所处的位置
在大多数组织中，此流程紧随客户流失挽留流程图（即时干预）之后，并交接给客户退款流程图（从申请到款项退回）。
它是客户生命周期中的一个步骤。
第 1 步: 销售线索资格认定流程图：从 MQL 到销售已接受线索
第 2 步: 销售流程图：从潜在客户到签署订单
第 3 步: 销售交接流程图：从赢单到客户成功
第 4 步: 客户导入流程图
第 5 步: 支持工单分流流程图
第 6 步: 客户支持升级流程图（一线到二线）
泳道式客户支持升级流程图：一线解决尝试、有记录的二线交接、严重程度与 SLA 复评、升级至研发。
第 7 步: 客户退订流程图（从申请到账户关闭） 当前位置
客户退订流程图：核对合同条款与通知期，先记录退订原因再谈挽留，挽留方案的权限上限，末期账单、数据导出、权限回收与流失归因。
第 8 步: 客户流失流程图（挽留行动到赢回）
客户流失流程图模板：风险信号、挽留行动、挽留结果判断、离场访谈、退出交接、赢回资格，以及流失分析的反馈循环。