例外
卡扣失败但客户已表明退订意愿时
不硬推重试，转入退订确定流程，避免重复扣款。
对在线独立创业者来说，流失信号从 Stripe 支付事件、退订日志、用量变化、退款咨询四处散着进来，卡扣失败悄悄断掉的订阅，往往很晚才发现。退订原因没被记下，客户就走了，下次该改什么来防流失也没留下线索。支付失败的挽回是抢时机，信号却不在一处，每次都错过。
这样的信号，会这样处理。
把真实进来的活儿归拢起来，连每一步依据什么判断，也一并留下来。
-
流失信号汇集
把支付失败、退订请求、用量骤降、退款咨询汇到一条队列，并附上账号历史。
判断 用账号标识把同一客户归并，去掉重复。为的是同一件事不处理两遍。 -
原因分类
按价格、功能、不使用、支付方式出错，把流失类型分开。
判断 先分清是卡扣出错还是有意退订。因为挽回办法完全不同。 -
挽回引导初稿
做好卡片更新引导、退订原因确认、再参与提议的初稿。
判断 支付失败走更新引导，有意退订先从确认原因开始。强力挽留留给人判断。 -
退款、重试准备
把退款条件与重试排期整理好，上报给人。
判断 涉及金额变动的动作只做准备，确定交给人。 -
挽回跟踪卡
做一张含账号、原因、下一步动作的卡片，作为未结项跟踪。
判断 挂上结案条件（挽回、确定退订），让它不会从队列里消失。
不知道原因，就不硬留。
现场真正会卡住的例外，我们提前定好。规则套不上的时候不硬办，连同依据一起交给人。
例外
退款与再购买混在一条消息里时
把退款开为主案例，把再参与意向分为单独案例，两个都保持存活。
例外
没有原因、只是用量悄悄骤降时
不擅自断定为退订，只作为再参与引导候选上报，交由人判断。
退款和再扣款，由人确定。
牵扯到钱、合同、个人信息和品牌的执行，只做到草稿为止；发送与敲定，要等人审批之后才动。
-
退款、订阅退订确定
是涉及金额与关系的不可逆动作，由人确认。
-
支付重试、再扣款
是向客户卡上扣款的动作，回退之前由人确定。
-
折扣、再参与提议
是会成先例的价格让步，属于人。
-
批量挽回发送
一旦发出就收不回，措辞与对象由人过目。
-
VIP、往来客户流失应对
关系上下文由人而非代码知悉。
用什么来确认
看挽回了多少。
支付失败恢复率
在导入前后实测失败支付中重新成功的比例。
退订防御率
在导入前后测量退订信号中未真正流失的比例。
退款处理时长
在导入前后测量从退款咨询受理到处理完成的时长。
规则
处理支付失败与退款时会涉及卡片、支付信息这类敏感个人信息，因此按目的最小化保存，支付处理在人确认之后再进行。
需要人亲自扛着的事变少了。
散落的核对和重复的回复先整理好递上来，员工就能把时间花在复核和例外上，人只看真正要紧的决定。
运营诊断待确认的事都堆到人身上。
卡片扣款一失败，订阅就悄悄断掉，取消原因也没留下，客户就走了。
备好的活儿先递上来。
支付失败和取消信号汇进一个队列，连挽回消息都备好，人只处理确认、发送和例外。
扣款失败挽回率
退订挽留率
退款处理时间
把这件事托付出去之前，大家会问什么
关于流失与支付失败挽回，大家实际上最先确认的那些问题。
支付重试是自动做的吗？
卡片更新引导与重试排期只准备到初稿，实际扣款由人确认后再进行。
挽留想退订的客户，会不会变成一种强迫？
先把退订原因分类，只做与价格、功能、流失类型相符的引导，强力挽留由人判断。
退款是 Velros AI 直接处理吗？
不会。只做到整理退款条件，实际退款由人确认后再执行。
