Billing, ERP, contracts, CRM and orders
Churn defined by the billing model
Monthly churn and risk queue with reasons
Retention queue, CRM and AI agent
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.
Business questions it answers
Ask your agent these questions once the case is live.
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
Where to activate
Daily list sorted by revenue at risk, with reason, signal date and owner; it closes the loop when the customer renews or buys.
Each customer past their cycle goes to the rep of the last purchase in the CRM or on WhatsApp; inactive ones go to the reactivation team.
Explains why a customer left or is at risk, with the billing, contract and contact history.
The monthly base comes quickly from billing or the ERP. The work is in writing the churn rule for your model and linking CRM and billing to the same customer. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
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.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
How churn happens in each model
The rule changes with the way you charge. Write yours before counting.
Definitions
Pitfalls that already happened
The sales table booked the cancellation as a negative line on the same sale. When summed, each contract's cancelled amount was zero.
Keep a dedicated cancellations table and answer from it, never from the sum of sales.
The dropout source stored when the office recorded the withdrawal, weeks after the student stopped. Churn landed in the wrong month.
Keep the record date and, when it exists, the real end-of-service date, and say which one you use.
Subscriptions stalled for months were cancelled at once in billing, and that month's churn jumped.
Close each exit at the earlier of cancellation and last payment plus one cycle.
Groups with several CNPJs or several billing accounts showed up as several active customers and as several churns when they left.
Consolidate into the single customer (for example, the main CNPJ) before counting.
Accounts with little contact history fired drop alerts from a variation of one or two events.
Require a minimum history and a drop in absolute value, not only in percentage.
A renewal card marked lost in the CRM was counted as churn, even with the customer still active on another product or plan.
Churn comes from product and billing status; the renewal pipeline is a signal, not an event.
Acceptance test
The case is done when every item passes.
- 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.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
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.
Build the "Churn and risk monitoring" case in my Nekt workspace following the rules at https://academy.nekt.com/en/casos/monitoramento-de-churn.md. 1) Find the source tables and confirm the columns the rules use. 2) Create a transformation at the stated grain applying every rule. 3) Run the acceptance test and show me the result of each item. 4) Create the case's context document in the workspace, leaving my clients' exceptions open for me to fill in.
Variations
For SaaS with product data: summed, versioned components, with usage only after it is proven against real churns.
Historical renewal rate by profile applied to expiring contracts, audited every month against actual renewals.
A prioritized queue of stalled customers feeding a re-engagement pipeline, without duplicating those already in contact.