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