---
id: casos/monitoramento-de-churn
area: CS
usage: widely used
effort: medium
grain: 1 row per customer x month for status, plus 1 row per at-risk customer per day
---

# Churn and risk monitoring

Who left, who is leaving and how much it weighs, with the right churn definition for each model: subscription, contract, tuition or repeat purchase.

## Executive summary

**For:** CS, retention and account management teams in any recurring business: subscription, contract, tuition or repeat purchase.

**What it solves**

- Monthly churn comes out with one yardstick for every team: customers, revenue, voluntary and involuntary.
- Risks show up before the due date, with the reason, the revenue at stake and an owner.
- Customers who stopped buying are seen before they become inactive.

**Why it matters:** Each team counts churn its own way: finance by the cancellation in billing, CS by the card in the CRM, sales by the last purchase. When the numbers do not match, nobody trusts the rate and retention becomes opinion. One yardstick, with date, reason and revenue, is what lets you act earlier and measure whether the action worked.

**Business questions it answers**

- What was last month's customer and revenue churn, and how much was due to failed payments?
- Who is at risk today and how much revenue does that represent?
- Which annual contracts expire in the next 60 days without a renewal?
- Which customers are past their own purchase cycle and have not come back?
- Were this quarter's cancellations from new or mature customers?
- What are the main reasons for leaving and how did they change this year?

**What you need**

- Billing, ERP or contract system connected to Nekt, with history
- The churn rule for your model: contract term, billing cycle or repeat-purchase window
- A single customer across billing, CRM and support

**What you get**

- A customer x month table with status: new, active, reactivated, churn
- Customer and revenue churn per month, split into voluntary and involuntary
- A daily risk queue with reason, revenue and owner
- An AI agent that explains every exit and every risk

## Detailed

### The problem

Churn is usually counted by the system's cancelled status, on the date someone recorded it, divided by the end-of-month base. That mixes database cleanup with real exits, makes one month look catastrophic and the next one great, and never separates who left by choice from who left because the card failed. In businesses without a contract, such as repeat purchase, churn does not even exist as an event: the customer just stops buying.

### Business rules

1. **One churn rule per billing model.** Write down what churn means for your model before counting. Subscription: the customer's recurring revenue goes to zero and does not come back in the next cycle. Contract: the current contract ends without renewal, and end of life is the earlier of end date and cancellation date. Rental: the contract no longer has any rent receipt scheduled. Repeat purchase without contract: inactive after N days without buying (for example, 365), with risk well before that. (Avoid: Using the system's cancelled status as the only definition.)
2. **The churn date is the end of service, not the record.** Cancellation and dropout sources record when the information was entered, not when the customer stopped. Keep both dates. In a database cleanup, billing cancels at once subscriptions that stalled months ago: close the churn at the earlier of the cancellation date and the last payment plus one cycle. Lost revenue is the last recurring value known before cancellation, because the MRR field zeroes when the subscription is cancelled. (Avoid: Counting churn on the day someone changed the status.)
3. **Rate over the base at the start of the period.** Monthly churn = customers in the base on the first day of the month who left during the month / base on the first day. New customers of the month stay out of the denominator. Compute it in customers and in revenue, always separately. For a quarter or year, recompute from the sums, never add monthly rates. (Avoid: Dividing cancellations by the end-of-month base, which already includes new customers.)
4. **Voluntary and involuntary are different churns.** Involuntary is an exit caused by a failed payment that was not recovered. An overdue invoice is not churn yet: track the cohort of subscriptions with a failure each month and count as recovered those that paid successfully within one billing cycle (30 days monthly, 90 quarterly, 1 year annual). In a real base, the recovery rate of closed months was close to 45%, so half of involuntary churn is recoverable through collection. (Avoid: Adding a declined card and a cancellation request into the same number.)
5. **Declared signals before inferred ones.** These go straight into the queue: cancellation or downgrade request, subscription set not to renew, contract notice, confirmed overdue installment, and a long cycle (annual, semiannual) expiring within 60 days or expired up to 45 days ago without renewal. Usage and engagement signals only come in after being tested against real churns. (Avoid: Starting with a usage score and leaving the cancellation request in a ticket.)
6. **Risk from the profile's own history.** For renewals, an explainable score works better than arbitrary weights: risk = 100 x (1 - historical renewal rate of the profile), where the profile combines billing cycle, payment method (automatic or manual) and whether it is the customer's first long cycle. Compute the rate only with contracts that already expired and had time to renew. (Avoid: The same risk weight for every expiring contract.)
7. **Cadence measured against the account itself.** A customer who buys without a contract is at risk after 1.5 times their own average purchase cycle, or after 270 to 365 days without buying when they bought more than once. A single purchase calls for contact 15 to 45 days later and becomes no repeat purchase between 90 and 365 days. Contact silence is also measured against the account's historical cadence, and a small base (fewer than 5 events) does not alert. (Avoid: One fixed cutoff of days without purchase for everyone.)
8. **Early churn is a different queue.** A cancellation shortly after the sale (for example, within 45 days, or 90 for large accounts) is a sales or onboarding problem, not a retention one. Flag those exits and analyze them apart. Classify the tenure of every churn in fixed bands: below 1 month, 1 to 3 months and 3 months or more. (Avoid: Adding first-month cancellations to the mature book's churn.)
9. **Active, paused and enabled are not the same.** An account enabled in the system is not an active customer: active means paid service in force. A delinquent customer who still has access stays in the base. Paused, frozen and onboarding are statuses of their own: the current book can be active plus onboarding plus paused, but the default answer to how many active customers uses active only. Before marking someone inactive, check the safeguards: recent purchase or billing, renewal in the next 30 days, an active-until date in the future. (Avoid: Using the app's account-enabled flag as active customer.)
10. **A brake before writing status in bulk.** If the routine writes status back to the CRM, it stops on its own when the source is stale (for example, no load for more than 30 days), when the record count dropped below expected, or when the run would deactivate more than 20% of the base. A late source makes it look like nobody bought anything. (Avoid: Syncing active and inactive every day without checking the source.)

### How churn happens in each model

The rule changes with the way you charge. Write yours before counting.

- **Subscription (SaaS, club, app)** → Recurring revenue goes to zero and does not return next cycle (`cancel_at_period_end, non_renewing, canceled`)
- **Fixed-term contract (agency, services)** → Current contract ends without renewal; notice is a signal
- **Long prepaid cycle (annual, semiannual)** → Risk from 60 days before to 45 days after expiry
- **Enrollment and tuition** → Dropout or cancellation; the record date is not the real date
- **Rental** → Contract with no rent receipt scheduled in the month
- **Repeat purchase without contract (B2B, distribution)** → Risk at 1.5x the average cycle; inactive after 365 days
- **Failed payment** → Involuntary only if not recovered within 1 cycle (`past_due, unpaid`)
- **Purchase with guarantee (digital course)** → A refund within the guarantee is not book churn

### Definitions

| Metric | Definition |
|---|---|
| Start-of-month base | customers with paid service in force on the first day of the month (contract, subscription or purchase within the window) |
| Customer churn | customers in the start-of-month base whose service ended during the month without renewal / start-of-month base |
| Revenue churn | sum of the last known MRR before cancellation of the customers who left in the month / start-of-month MRR |
| Involuntary churn | an exit caused by a failed payment not recovered within 1 billing cycle |
| Recovery rate | subscriptions with a failure in the month that paid successfully within 1 cycle / subscriptions with at least one failure in the month |
| Early churn | an exit up to N days after the sale (for example, 45 days, or 90 for large accounts) |
| Reactivated | a customer who pays or buys again after leaving (in repeat purchase, after a gap of 365 days or more) |
| At-risk customer | an active customer with at least one declared, billing or cadence signal on the day |
| Revenue at risk | sum of monthly recurring revenue of the at-risk customers on the day |

### Pitfalls

- **How much we cancelled came out as zero.** The sales table booked the cancellation as a negative line on the same sale. When summed, each contract's cancelled amount was zero. How to avoid: Keep a dedicated cancellations table and answer from it, never from the sum of sales.
- **The record date became the exit date.** The dropout source stored when the office recorded the withdrawal, weeks after the student stopped. Churn landed in the wrong month. How to avoid: Keep the record date and, when it exists, the real end-of-service date, and say which one you use.
- **A database cleanup inflated one month.** Subscriptions stalled for months were cancelled at once in billing, and that month's churn jumped. How to avoid: Close each exit at the earlier of cancellation and last payment plus one cycle.
- **One customer counted several times.** Groups with several CNPJs or several billing accounts showed up as several active customers and as several churns when they left. How to avoid: Consolidate into the single customer (for example, the main CNPJ) before counting.
- **Silence alert on a small account.** Accounts with little contact history fired drop alerts from a variation of one or two events. How to avoid: Require a minimum history and a drop in absolute value, not only in percentage.
- **Lost renewal counted as churn.** A renewal card marked lost in the CRM was counted as churn, even with the customer still active on another product or plan. How to avoid: Churn comes from product and billing status; the renewal pipeline is a signal, not an event.

### Acceptance test

- [ ] For each of the last 12 months: start base + new + reactivated - churns = end-of-month base.
- [ ] No churn has lost revenue equal to zero; all use the last MRR before cancellation.
- [ ] Voluntary churn + involuntary churn = total churn, and every churn has a reason filled in or marked as no reason.
- [ ] Every subscription set not to renew and every long cycle expiring within 60 days without renewal shows up in the risk queue the next day.
- [ ] No customer appears as churn in two different months without a reactivation between them.

### Context document

```text
Churn and risk monitoring
- Churn follows the billing model's rule: <subscription | contract | repeat purchase>. For repeat purchase, inactive means more than <N> days without buying.
- The churn date is the effective end of service. If only a record date exists, say so in the answer.
- Churn rate = exits in the month / active base on the first day of the month. Customers and revenue always separate. For longer periods, recompute from the sums.
- Lost revenue is the last known MRR before cancellation. Zero MRR after churn does not mean a free customer.
- Separate voluntary from involuntary churn. An overdue invoice only becomes churn if it is not paid within 1 billing cycle.
- Risk comes first from declarations and billing: cancellation request, non-renewal, contract notice, overdue installment, long cycle expiring.
- Early churn (up to <N> days after the sale) is analyzed separately.
- An active customer has paid service in force. An account enabled in the system is not an active customer. Paused and onboarding are statuses of their own.
- Always report the reason, date and revenue of each exit or risk.
Client exceptions:
- <client>: contract notice period of <N> days; the notice counts as an exit request.
- <client>: product <product> excluded from churn because it is a one-off sale.
```

### Variations

- **Account health score:** For SaaS with product data: summed, versioned components, with usage only after it is proven against real churns.
- **Renewal forecast:** Historical renewal rate by profile applied to expiring contracts, audited every month against actual renewals.
- **Reactivating inactive customers:** A prioritized queue of stalled customers feeding a re-engagement pipeline, without duplicating those already in contact.