Reducing Involuntary Churn Through Smarter Dunning: A Product Case Study

通过更智能的催收减少非自愿流失：一份产品案例研究

A note before you read: I’m a Scrum Master, not a titled Product Owner. What follows is my own product thinking, applied to a domain I know well from sitting close to subscription billing systems in my day-to-day work. It’s built on general, publicly known patterns in subscription billing, not on any employer’s proprietary data. I’m sharing it because I think the best way to show you can do a job is to actually do a piece of it. 在阅读之前，请注意：我是一名 Scrum Master，而非正式的产品负责人（Product Owner）。以下内容是我个人的产品思考，应用于我在日常工作中因紧密接触订阅计费系统而非常熟悉的领域。这些思考基于订阅计费中通用的、公开的模式，而非任何雇主的专有数据。我分享这些是因为我认为展示工作能力的最好方式，就是实际完成其中的一部分工作。

The problem

问题所在

Picture a mid-market B2B SaaS company with around 15,000 paying accounts on monthly and annual plans. Revenue is leaking, not because customers are choosing to leave, but because their payments are simply failing: expired cards, insufficient funds, banks declining transactions for no visible reason. This is involuntary churn, and it’s a different beast from voluntary churn. Customers aren’t unhappy. They just fell through a crack in the payment flow. Which means it’s fixable through better product design, not through discounts or retention calls. 想象一家拥有约 15,000 个月付和年付付费账户的中型 B2B SaaS 公司。收入正在流失，原因并非客户选择离开，而是因为支付失败：信用卡过期、余额不足、银行无故拒绝交易等。这就是“非自愿流失”，它与“自愿流失”截然不同。客户并非不满意，他们只是在支付流程中掉进了“坑”里。这意味着可以通过更好的产品设计来解决，而不是通过折扣或挽留电话。

I’ve spent years adjacent to this problem, facilitating delivery on Zuora Billing and Zuora Revenue workstreams as a Scrum Master. I’ve watched dunning configuration, collections workflows, and payment-retry logic get built, without ever owning the decisions about what to prioritize or why. This case study is me stepping into the seat next to the one I usually sit in: framing the problem, making the calls, defining what ships. 多年来，我一直处于这个问题边缘，作为 Scrum Master 推动 Zuora Billing 和 Zuora Revenue 工作流的交付。我目睹了催收配置、收款流程和支付重试逻辑的构建，却从未拥有关于优先级或决策原因的决定权。这份案例研究是我从通常的位置跨越到决策席位：界定问题、做出决策、定义交付内容。

Who actually feels this

谁真正感受到了痛点

Two personas drive the priorities here: 这里有两个驱动优先级的人物画像：

The Billing Ops Lead. She’s watching failed-payment volume climb every month, manually chasing down accounts, and has no visibility into which failures are recoverable versus dead ends. She needs the system to do the triage for her. 计费运营主管。她每月看着支付失败量攀升，手动追缴账户，却无法分辨哪些失败是可以挽回的，哪些是死胡同。她需要系统为她进行分类处理。

The end customer. He doesn’t know his card expired last week. He finds out when his account gets suspended mid-project. He’s not churning by choice, he’s churning by neglect, and a single well-timed email would have kept him. 终端客户。他不知道自己的卡上周过期了。直到项目进行到一半账户被暂停时，他才发现。他并非主动流失，而是因为疏忽，而一封时机恰当的邮件本可以留住他。

Setting goals that mean something

设定有意义的目标

It’s tempting to jump straight to “reduce churn.” That’s not a goal a team can build against. I broke it down into three measurable targets for a two-quarter horizon: 直接设定“减少流失”的目标很诱人，但这不是团队可以执行的目标。我将其拆解为两个季度内的三个可衡量目标：

• Recover at least 30% of failed payments within the retry window, up from an assumed baseline near 12%. 在重试窗口内至少挽回 30% 的失败支付，高于约 12% 的假设基准。
• Cut the average time between a failed charge and account resolution from roughly 9 days to under 3. 将支付失败到账户恢复的平均时间从约 9 天缩短至 3 天以内。
• Reduce manual billing-ops intervention on recoverable accounts by half. 将针对可挽回账户的人工计费运营干预减少一半。

Each of these is something engineering can build toward and something I can measure without ambiguity. 每一项都是工程团队可以努力的方向，也是我可以明确衡量的指标。

Prioritizing with RICE, not gut feel

用 RICE 模型而非直觉进行优先级排序

I had five candidate features on the table: smart retry timing based on card networks, proactive card-expiry notifications, a self-serve payment update page, an internal dunning dashboard for billing ops, and a machine-learning based failure-reason classifier. 我手头有五个候选功能：基于卡组织的智能重试时机、主动的信用卡过期通知、自助支付更新页面、内部计费运营催收仪表盘，以及基于机器学习的失败原因分类器。

Running each through RICE (Reach, Impact, Confidence, Effort) surfaced something I didn’t expect: the flashy ML classifier scored lowest, not because it wasn’t valuable, but because effort was high and confidence in near-term impact was low without more failure data first. The self-serve payment update page and smart retry timing scored highest. Cheap to build, directly addressed the biggest reach, and didn’t require new infrastructure. That’s the RICE model doing its job: keeping the roadmap honest instead of chasing the most interesting technical problem. 通过 RICE（覆盖范围、影响力、信心、工作量）模型评估后，结果出乎意料：炫酷的机器学习分类器得分最低，不是因为它没价值，而是因为工作量大，且在缺乏更多失败数据的情况下，对短期影响的信心不足。自助支付更新页面和智能重试时机得分最高。它们构建成本低，直接解决了覆盖面最大的问题，且无需新基础设施。这就是 RICE 模型的作用：保持路线图的务实，而不是盲目追求最有趣的技术问题。

MVP first, sophistication later

先做 MVP，再谈复杂化

Phase 1 (MVP): Smart retry timing tuned to card network patterns, a self-serve card-update page linked from suspension emails, and a lightweight ops dashboard showing recoverable vs. dead accounts. 第一阶段 (MVP)：针对卡组织模式调整的智能重试时机、从暂停通知邮件链接的自助信用卡更新页面，以及展示可挽回与死胡同账户的轻量级运营仪表盘。

Phase 2: Proactive expiry notifications 14 and 3 days out, and a failure-reason classifier feeding the retry logic instead of running on a fixed schedule. 第二阶段：提前 14 天和 3 天的主动过期通知，以及将失败原因分类器接入重试逻辑，而非运行在固定计划上。

Sequencing it this way meant we could ship something measurable in one quarter and let Phase 2 be informed by what Phase 1 actually taught us about failure patterns, rather than guessing upfront. 这样排序意味着我们可以在一个季度内交付可衡量的成果，并让第一阶段学到的失败模式为第二阶段提供依据，而不是预先猜测。

The trade-off I’d defend in an interview

我在面试中会捍卫的权衡

The hardest call was deprioritizing the ML classifier despite it being the “smartest” solution on paper. Engineering wanted to build it first. I pushed back because we didn’t yet have clean, labeled failure data to train it well, and shipping a mediocre model would have delayed the parts of the fix that didn’t need machine learning at all. Sequencing matters as much as selection. A roadmap isn’t just a list of good ideas, it’s an argument for what order they earn the right to exist in. 最艰难的决定是降低机器学习分类器的优先级，尽管它在纸面上是“最聪明”的方案。工程团队想先做它。我拒绝了，因为我们还没有干净、已标注的失败数据来训练它，而交付一个平庸的模型会推迟那些根本不需要机器学习的修复工作。排序与选择同样重要。路线图不仅仅是一堆好点子的清单，它更是关于这些点子以何种顺序获得存在权的论证。

Why this translates from Scrum Master to Product Owner

为什么这能从 Scrum Master 转化为产品负责人

Running sprints for two years on this exact system taught me the constraints before I ever had to make the calls. I know what “just add a retry” costs in engineering time because I’ve watched teams size that work. I know which stakeholders will push for the shiny model over the boring fix, because I’ve facilitated that argument in refinement sessions. For me, the gap between Scrum Master and Product Owner was never about knowledge. It’s about who gets to decide. This case study is what I do with the decision rights when I have them. 在这个系统上运行了两年冲刺（Sprint），让我在做出决策前就了解了约束条件。我知道“加个重试”在工程时间上意味着什么，因为我见过团队评估这项工作。我知道哪些利益相关者会为了炫酷的模型而放弃枯燥的修复，因为我在需求细化会议中协调过这类争论。对我而言，Scrum Master 和产品负责人之间的差距从来不是知识，而是谁拥有决定权。这份案例研究就是我拥有决策权时所做的事情。

If you’re hiring for a Product Owner or Product Manager role and want to talk through how I’d approach a real backlog, I’d genuinely enjoy that conversation. Find me on LinkedIn. 如果您正在招聘产品负责人或产品经理，并想探讨我如何处理真实的待办事项列表（Backlog），我非常乐意进行交流。请在 LinkedIn 上找到我。