Involuntary Churn

Why it deserves its own bucket

Voluntary and involuntary churn look identical in a cancellation count and are opposite problems. Voluntary churn is a verdict on the product, the price or the onboarding — the customer evaluated and left. Involuntary churn is a verdict on your billing plumbing. The customer never decided anything; a card expired, an issuer declined a cross-border charge, or a bank flagged a recurring transaction as suspicious.

Blending them corrupts both. Your voluntary churn looks worse than it is, sending product and pricing teams chasing a problem that lives in payments. And the recoverable portion disappears into an aggregate where nobody owns it. Any serious retention effort separates the two before doing anything else.

The three timestamps that matter

Failed payments create a multi-week limbo that most metric definitions handle badly, because there are three distinct moments:

• Charge fails. The subscription is still active; the customer usually does not know yet.
• Dunning runs. Retries and card-update emails over a window of days or weeks. Most of what will be recovered is recovered here.
• Write-off. Retries exhausted, the subscription is cancelled.

Recognising churn at the first moment overstates it badly, since most of that revenue returns. Recognising it only at write-off means MRR counts revenue that has not been collected for weeks. The common convention splits the difference with a delinquency window: an account past due beyond a fixed number of days counts as churned. Thirty days is the usual default, with sixty days as a looser alternative.

That window is a policy, not a fact, and it visibly moves your reported churn. Bastle's metrics engine treats it as a workspace-level setting alongside the other definitional choices — trial handling, whether a 100% coupon counts as churn, the annual churn lookback — so the number can be recomputed on a different window rather than argued about. Baremetrics exposes the delinquency window too; per their own documentation it is close to the only metric rule they let you configure.

How much of churn is involuntary

Enough to matter, and the honest answer is that credible public figures are scarce and mostly published by vendors selling recovery products. Baremetrics markets its Recover product on the claim that roughly 9% of MRR is at risk from failed payments — a vendor's own number about a vendor's own category, useful as an order of magnitude and not as a benchmark. Treat any specific percentage in this area, including that one, as directional.

What is not in doubt is the shape: card expiry is the largest single cause and is entirely predictable in advance, insufficient funds is next and is highly recoverable on a retry timed to payday, and hard declines for fraud or closed accounts are mostly unrecoverable. Measure your own split before buying anything to fix it.

What actually reduces it

Roughly in order of return on effort: prompt for a new card before the stored one expires, since the expiry date is already in your database; retry on a schedule that accounts for payday cycles rather than fixed 24-hour intervals; use network tokens or account updater services so reissued cards keep working without customer involvement; email the customer with a direct update link rather than relying on the payment processor's default template; and set a retry limit that stops before the messaging starts damaging the relationship.

Bastle ships a Recover surface for failed-payment recovery. It is the sort of feature worth judging on your own measured recovery rate rather than on any vendor's ROI claim, including ours — the honest test is what share of at-risk MRR comes back, compared to what came back before.

Measuring the recovery, not the failure

The metric a dunning process should be judged on is recovery rate: revenue recovered divided by revenue that entered dunning. Involuntary churn rate is the residual after that process runs, and it moves for two entirely different reasons — more failures, or worse recovery. Track both, or a payments outage and a broken retry job will look the same on your dashboard.