How to Handle Failed Payments Before Dunning Automation

Devmosh's playbook outlines a five-step manual process for payment recovery, emphasizing data collection and segmentation to inform effective dunning automation. This approach prioritizes understanding before scaling.

The Reddit user devmosh outlined a structured approach to managing failed recurring payments, advocating for a manual recovery queue before full automation. This strategy aims to prevent churn by actively engaging with customers whose payments have failed, rather than relying solely on automated dunning. The core premise is to understand recovery dynamics through human intervention first.

devmosh's playbook details a five-stage process for payment recovery. It prioritizes manual intervention and data collection to inform later automation, ensuring the dunning process is built on observed customer behavior and recovery patterns. The system emphasizes segmentation and role-based access for critical billing actions.

Build the Failed Payment Queue

The initial step involves establishing a centralized queue for all failed recurring payments. Each entry in this queue requires specific data points to provide a comprehensive view of the payment issue and customer context. These fields include the customer's name, their plan and associated MRR, the payment provider used, the precise reason for failure, and the failed amount. Further context is provided by tracking the number of failed attempts, the date of the last successful payment, and the customer's last active date. Crucially, the account owner, next retry date, message status, and recovery status are included, alongside a field for internal notes, enabling a detailed audit trail and coordinated action.

Segment Customer Failures

Not all failed payments warrant the same response; devmosh emphasizes segmentation. The playbook advises categorizing failures into distinct groups to tailor recovery efforts. These segments include new inactive customers, currently active customers, and high-value accounts, each potentially requiring different communication or intervention. Specific payment issues are also segmented, such as repeated failures, general card failures, and SEPA/mandate issues. Furthermore, customers with open support tickets are identified as a separate group, suggesting a need for coordinated communication to avoid conflicting messages.

Define Manual Actions

Before any automation, devmosh outlines a set of manual actions that human operators should be able to perform. These actions are designed to directly address payment failures and manage customer relationships. Operators should be able to mark a customer as contacted, send a recovery email, or schedule a follow-up. Technical actions include retrying a payment or syncing with the payment provider. Customer-centric options involve extending a grace period or notifying the account owner. The ability to suspend an account is restricted, only permissible when predefined conditions are met, emphasizing a cautious approach to service interruption.

Build the Internal Panel

To facilitate these manual actions, devmosh recommends constructing an internal panel. This panel serves as a unified interface, integrating data from disparate systems like Stripe or Mollie for billing and an internal database for customer information. The example provided uses UI Bakery to connect these data sources, creating a single recovery queue for support teams. The panel incorporates "safe actions" such as opening customer details, updating recovery status, assigning an owner, and adding notes. It also allows triggering emails or API actions and scheduling next follow-ups. Role-based access control is critical: support staff can update notes, but only administrators can suspend accounts or override plans. All changes to billing or account state are logged for auditing purposes.

Automate Later, After Process Stability

The final stage of devmosh's playbook is automation, but only after the manual workflow has proven effective and stable. The sequence is explicit: manual queue first, then a stable process, and finally automation. This sequential approach prevents the risk of automating a recovery flow that is not fully understood or optimized. By first observing and refining the manual process, founders can ensure that automated dunning reflects actual successful recovery patterns, rather than embedding inefficient or ineffective procedures.

What We'd Change

The devmosh playbook offers a robust framework for understanding and managing payment failures, especially for early to mid-stage SaaS companies. However, its emphasis on manual intervention carries inherent scaling limitations and potential for human error. For companies experiencing high volumes of failed payments, the overhead of a fully manual queue, even with a dedicated internal panel, could quickly become prohibitive. The "recovery status" and "message status" fields, while useful, depend heavily on consistent human input, which can vary across support agents.

The recommendation to build an internal panel using a tool like UI Bakery is practical for integrating disparate data sources. However, the initial setup and maintenance of such a custom tool still represent a development cost. For many early-stage founders, leveraging advanced features within existing dunning solutions (e.g., Stripe's Smart Retries, Churn Buster, ProfitWell Retain) might offer a faster path to data-driven recovery without the custom build. These platforms often provide granular segmentation and automated action capabilities that mirror devmosh's manual steps, but at scale.

Furthermore, the playbook does not explicitly address the timing of manual interventions in relation to automated retries from payment processors. Most payment gateways automatically retry failed payments multiple times. Integrating manual actions effectively requires understanding when these automated retries cease and when human intervention becomes most impactful. A more refined playbook would specify triggers for manual review, perhaps after a certain number of automated retries have failed, or for specific high-value customer segments only. This would optimize human effort.

Landing

The structured approach to payment recovery, as outlined by devmosh, underscores a fundamental principle: understanding the problem precedes scaling the solution. By first establishing a manual queue, segmenting customer failures, and defining human actions, founders gain direct insight into the nuances of payment recovery. This disciplined process ensures that when automation is eventually implemented, it is built upon a foundation of proven workflows and observed customer behavior, rather than assumptions. The result is a dunning system that is both effective and resilient.

Pull quote: “”