CRM & operations

Voluntary vs. involuntary churn: a guide for subscription brands

Define voluntary and involuntary churn, calculate a clean opening-cohort rate, and build practical cancellation and failed-payment responses.

Admoji team
Concept illustration of one subscriber path dividing into a deliberate cancellation and a failed payment, on a dark navy background.
Two exit paths need different diagnoses. Concept illustration.
On this page

A subscription can end because a customer wants to leave or because the next charge never goes through. Those outcomes look alike in a monthly total, but they point to different work. Treating every failed charge as churn overstates loss; treating every canceled plan as a billing problem misses the product or service reason behind it.

This guide gives subscription teams a workable definition, a consistent cohort example, and a review routine for each path. The numbers are illustrative. Set the actual loss date, grace period, and customer unit with your billing and finance owners before publishing a rate.

THE SHORT VERSION

  • A failed renewal becomes involuntary churn only when it meets your documented terminal-loss rule.
  • Use an opening customer cohort and report voluntary, involuntary, and pending outcomes separately.
  • Match cancellation fixes to customer reasons and payment recovery to the provider response and customer action required.

1. Two exits that need different responses

Voluntary churn is a customer's deliberate decision to end a subscription. They may cancel because the product no longer fits, a delivery is too frequent, the price is too high, or an issue was never resolved. Involuntary churn is a subscription lost without an expressed choice to leave, often after a renewal payment cannot be collected and the recovery process ends. The distinction matters because the remedy is different: product, service, and plan changes address many deliberate cancellations; billing diagnosis and a clear payment-update path address many failed renewals.

A single failed payment is an event, not necessarily a lost customer. Stripe describes a subscription moving to past_due when an automatic renewal cannot be paid, and then to canceled or unpaid after retry handling according to settings. Shopify Subscriptions can retry and then skip, pause, or cancel depending on its configuration. Neither platform status alone tells your team when to count a customer as gone. Stripe subscription status reference; Shopify Subscriptions settings.

Start with a simple question for every case: did the customer choose to stop, or did the billing path fail while they still intended to receive the next order? A support-requested cancellation is voluntary even if a card had failed earlier. A bank decline is a billing event even if the customer later chooses to cancel.

2. Decide when a customer is actually lost

Write a terminal-loss rule before calculating a rate. For example: “Count an opening-cohort customer as involuntarily churned on the date their last active subscription reaches the end of the approved recovery window and service ends because payment remains unresolved.” This is an illustrative policy; your contract, access rules, subscription app, and finance practice determine the real one. Record both the first failed attempt and the terminal date. They answer different questions.

Keep past_due, retry scheduled, grace period, and customer action required in a pending queue. A provider may leave a subscription past_due after retries or set it to unpaid, so the business rule should specify whether and when that status ends the customer's entitlement. Stripe documents these configurable end states. Stripe retry and final-state options.

For customer churn, decide whether you count people or subscriptions. A customer with two plans who cancels one may have subscription churn but remains a customer. This guide uses one customer as the unit and counts loss only when that customer's last qualifying subscription ends. If a customer schedules cancellation for period end, record the request immediately but count the loss when service actually ends under your policy. Stripe exposes cancel_at_period_end for this distinction. For that scheduled cancellation, canceled_at records when the request was made, not the effective end; use ended_at and your service rule to determine the loss date. Stripe subscription object reference.

3. Choose a denominator you can explain

For a monthly customer churn rate, take the customers with a qualifying active subscription at the start of the month. Use the same timezone and a timestamp boundary such as 00:00 UTC on September 1 through just before 00:00 UTC on October 1. This opening group is the denominator for both voluntary and involuntary customer churn. Exclude customers who first subscribe during September; track their activation and early cancellations in a separate new-customer cohort. Otherwise acquisition growth can dilute churn without changing the experience of existing subscribers.

Numerator events are terminal exits from that opening group during the month, classified by cause. A person can contribute at most one terminal customer exit in that period. When a failed payment is recovered before the terminal rule is met, keep the recovery in billing operations and leave the customer in the cohort. If a case was still pending at the reporting cutoff and later pays before terminal loss, record a later recovery, not a reactivation. If the customer had already met the terminal-loss rule and later returns, record a reactivation in the later period and preserve the frozen churn figure; if you routinely restate prior periods, publish a consistent restatement policy.

Some teams use average customers or subscriptions as their denominator. Those can be valid for another question, but do not mix them with an opening-cohort numerator and call the result comparable. Put the unit, start population, exclusions, and loss date in the chart label. The same discipline applies to revenue: a customer paying $10 and one paying $100 each count once in customer churn, while their revenue impact differs. Our subscription box billing guide covers the underlying renewal decisions.

4. Work a month from a real ledger shape

Here is a fully illustrative September cohort. On September 1, 1,000 customers have an active, paid subscription. During September, 40 of them reach the effective end of a requested cancellation. Another 20 reach the documented terminal-loss rule after failed renewals. At the October 1 cutoff, 15 more have an unresolved payment issue but remain in the approved recovery window. Ten failed renewals were recovered before any terminal loss. Eighty people started subscriptions during September and are excluded from this opening-cohort calculation. Assume no other exits and one qualifying subscription per person.

Illustrative September customer cohort
Opening-cohort outcomeCustomersTreatment
Opening active customers1,000Denominator
Voluntary terminal exits40Numerator: voluntary
Involuntary terminal exits20Numerator: involuntary
Payment issue still pending at cutoff15Still in opening cohort
Failed renewal recovered before terminal loss10Still in opening cohort
Other opening customers still active915Still in opening cohort
Closing opening-cohort customers9401,000 − 40 − 20

Voluntary customer churn is 40 ÷ 1,000 = 4%. Involuntary customer churn is 20 ÷ 1,000 = 2%. Total customer churn for that opening cohort is 60 ÷ 1,000 = 6%. The 15 pending cases and 10 recovered cases are part of the 940; they are not extra customers to add to the denominator. The 80 new customers are neither added to that 1,000 nor subtracted from its exits. Download the cohort worksheet to replace these example figures with your own.

Concept illustration of a reconnected payment and subscriber loop beside an open connection and a clock.
A failed payment stays in the recovery queue until it meets a documented outcome. Concept illustration.

5. Keep customer churn and revenue churn apart

Customer churn tells you how many relationships ended. Revenue churn tells you how much recurring value from an opening revenue base was lost. If each of the 60 illustrative leavers paid a different monthly amount, multiplying 60 by an average price pulled from all current subscribers would hide the mix. Instead, freeze the opening cohort's recurring revenue and sum the opening recurring value attached to each terminal exit. Divide that lost recurring value by the same cohort's opening recurring revenue, in one currency and with documented discount, tax, shipping, and plan-change rules.

For example, assume there are no downgrades or other revenue contractions among retained customers. If the 1,000 opening customers carried $50,000 in monthly recurring subscription value and the 60 terminal exits represented $2,400 of that opening value, gross customer churn would still be 6%, while gross revenue churn would be 4.8% ($2,400 ÷ $50,000). Those numbers are illustrative and are not implied by the customer counts above. Record voluntary and involuntary lost recurring value separately if the source ledger supports it. In a full gross revenue churn calculation, also include contraction such as downgrades among customers who remain, using the same recurring-value basis. Keep that contraction separate from revenue lost through full customer exits. Expansion and reactivation need their own lines and a stated inclusion policy when you calculate net revenue retention or net revenue churn.

For boxes with changing contents or shipment cadence, decide whether the value basis is contracted monthly equivalent, expected next shipment, or collected revenue. A missed order is not always a lost subscriber; a lost subscriber is not always one missed order. Finance and subscription operations should sign off on the shared definitions before a dashboard becomes a target.

6. Match the action to the cause

A useful churn review does not put every exit into a single “save” campaign. Capture a short reason taxonomy, an owner, the next action, and evidence that the action helped. Use customer feedback only for the purpose collected and keep payment records out of the cancellation-reason table.

Starting action map; adapt to your product and policy
SignalWhat to inspectUseful responseMeasure
Too frequent or too much productCadence, skips, unused stockOffer a clear skip or longer interval when availableAccepted changes and later retention
Price or value concernPlan fit, changes in price, delivered valueExplain options plainly; test a suitable lower commitmentReason trend and post-change retention
Service or fulfillment problemLate, missing, or damaged orders and support resolutionResolve the specific problem before proposing another termRepeat complaints and cancellations
Soft payment failureProvider response and scheduled retryFollow approved retry schedule; send a concise update linkRecovered invoices before terminal cutoff
Hard decline or authentication requiredIssuer code and customer action neededAsk for a new method or required authenticationCustomer-completed updates and successful renewal

Cancellation feedback is directional: a reason selected in a portal does not prove causality. Pair it with product, service, and billing records at an aggregate level. The order management process flow is a useful companion when late or incorrect orders appear in cancellation notes.

7. Build a recovery loop with stopping rules

Begin with the failed invoice or billing attempt, not an automatic conclusion about intent. Check the payment provider's failure category, whether a retry is already scheduled, which payment method the subscription will actually use, and whether the customer must act. Stripe says it does not execute automatic retries when no method is available or a hard decline is returned. Its non-retryable decline codes include authentication_required; a scheduled automatic retry will not execute until a new payment method is detected. Separately, the customer may need to complete authentication through a secure provider flow. Stripe also warns that updating only a customer-level default may leave a subscription-level default in place. Stripe retry documentation.

  1. Classify and queue. Store the subscription ID, invoice ID, first failure time, status, next authorized attempt, and terminal cutoff. Use stable IDs; do not paste full card details or sensitive personal data into the worksheet.
  2. Use the configured retry policy. Check provider settings and the issuer response. Set a bounded schedule that matches the payment method and customer promise. Do not blindly submit repeated attempts when authentication, consent, or a new method is required.
  3. Give the customer a direct route. A short notice should state that the renewal did not complete, what happens next, and where to update or authenticate securely. Shopify documents payment-update links and notes that a bank may require the customer to confirm a recurring purchase. Shopify subscription management.
  4. Close each case once. Mark recovered before cutoff, terminal involuntary loss, customer-requested cancellation, or unresolved at cutoff. Preserve timestamps so a later recovery does not masquerade as a never-failed renewal.

Our subscription payment gateway guide helps teams ask how retries, update links, authentication, and status events travel across their stack.

8. Communicate without trapping subscribers

A cancellation flow should be easy to complete and honest about its effective date. Offer a skip, pause, cadence change, or support contact only when each is genuinely available and relevant. If a customer declines an alternative, complete the cancellation and confirm what will be charged, shipped, or accessible until the end. Shopify's subscription customer experience documents manage, pause, skip, cancel, and payment-update actions for its app; check the exact options in yours. Shopify subscription customer experience.

For payment failures, say “we could not complete your renewal” rather than “your account is canceled” while the case is still recoverable. Link to a secure account or provider-hosted update page and identify the expected next step. Do not ask people to reply with card numbers or route them through a generic survey. If service is paused during a grace period, say so plainly. Align the message with the actual access and shipment rules; support should see the same state the customer sees.

Send only the notices needed for that stage. A gentle initial reminder, a notice when customer action is required, and a clear final outcome are more useful than escalating urgency without new information. Record delivery and resolution so support can stop messages after recovery or cancellation. The aim is to preserve a willing subscriber's access, not to make leaving difficult.

9. Review the system, not just the headline rate

At each monthly close, have billing, support, product, and finance review the same opening cohort. Keep one row per period with the opening customer count, each terminal exit type, unresolved payment cases at cutoff, recoveries before terminal loss, new customers excluded, and a note on the loss rule. The downloadable worksheet has those columns and the worked example. It contains no customer-level personal information.

  • Validate the boundary: timezone, opening timestamp, eligible plans, trial handling, and whether multiple subscriptions roll up to one customer.
  • Reconcile events: cancellation requested versus effective, first failure versus final state, recovered invoice versus reactivation, and duplicates across systems.
  • Inspect causes: cancellation reasons alongside order and support issues; payment declines alongside method type, provider settings, and required customer action.
  • Compare cohorts: plan, tenure, acquisition month, and billing cadence with adequate sample sizes. Do not mistake a mix shift for an improvement in retention.
  • Assign an owner: one change to test, a date to review it, and the measure that would show whether it helped.

Keep financial performance alongside retention. A brand can lower churn while spending heavily to keep low-margin subscriptions; another can accept some plan downgrades that preserve a useful relationship. For a wider view of media spend against total revenue, see our MER versus ROAS guide. If your team needs a single view of orders, customer history, and marketing performance, Admoji's public platform overview is a starting point for evaluating the fit against your workflow.

Sources & further reading

Primary documentation reviewed September 28, 2026. Platform behavior can change; follow the linked documentation for current requirements. Examples in this article are illustrative.

EXPLORE ADMOJI

Map churn to the customer and the renewal.

Use the worksheet to agree on a loss rule, then compare your cancellation and billing workflow with Admoji's published platform overview.

Request access to Admoji