Billing, CRM, support, product and conversations
Declared signals first; usage only if it predicts churn
Severity, reason and MRR at risk by account
CS queue, alerts, CRM and AI agent
What it solves
- CS gets a short queue of accounts with a concrete reason and MRR at risk.
- The alert only uses signals proven to be tied to churn, with no false comfort.
- Every risk change is recorded, so you can measure whether the score is right.
Business questions it answers
Ask your agent these questions once the case is live.
What you need
- Billing and CRM or support tool connected to Nekt
- The single customer across billing, CRM, product and support
- A history of churns to test each signal before using it
What you get
- A daily table with severity, reason and MRR at risk by account
- A history of severity changes to measure accuracy
- A CS action queue sorted by MRR at risk
- An AI agent that builds the account profile with the evidence
Where to activate
A daily or weekly list sorted by severity and MRR, with a reason and next action for each account.
Severity and reason stored on the company or in the CS tool, where the team already works.
Builds the account's retention profile with the signals, the MRR and the customer's statements from the new text.
Start with the declared signals, which are few and reliable. Usage and conversations come in later, only if they prove to precede churn. The detailed view has the business rules, the pitfalls and the acceptance test. Or send everything straight to your agent with the Nekt MCP.
The typical health score sums usage, logins and engagement into a 0 to 100 grade and paints almost the entire base green. In one real base, almost none of the customers who canceled had a low-usage signal, and most were active in the days before leaving. Meanwhile, the signals that actually warn (cancellation request, overdue invoice, contract with no renewal) sit in systems CS doesn't look at every day.
How it is usually done, and the rule
Each row is a mistake that already happened in practice.
By default, the verdict uses what the customer or billing states: a cancellation or downgrade ticket or case, a subscription set not to renew (cancel_at_period_end in Stripe, non_renewing in Chargebee), an invoice overdue for more than N days and a contract expiring with no renewal negotiation open. Usage, logins and engagement are inferences and need proof.
For each signal, measure in how many of the last months' churns it was present before cancellation and in how many accounts that didn't cancel it also appeared. In one real base, the usage recency signal was recorded in under 1% of churns, response rate and activation in none, and those who had the signal were active in the 5 days before canceling. The usage axis was removed from the verdict.
Call the no-problem state something like billing up to date, no exit request. Never report the share of the base in that state as the share that is healthy. A rule whose only possible outputs were healthy or great stamped most MRR as good with nothing that could contradict it.
If usage goes in, compare it with the account itself: a baseline of 6 full months before the current month (month -7 to month -2). Require a drop in both percentage and absolute terms at the same time (for example, -15% and at least 3 units), so small accounts don't alert on noise. Without a stored daily snapshot there is no trend: the product database often deletes old data.
A null component due to missing data doesn't mean no risk, and zero engagement without a validated source doesn't mean risk. Mark the account as missing data for that component and don't raise an alert on it.
In the CRM, each email reply carries the entire quoted conversation. Before sending it to AI or counting signals, cut the history at the quote markers: "On ... wrote:", the Portuguese "Em ... escreveu:", the Portuguese Outlook header "De: ... Enviada em:", lines starting with ">" and nested quotes. Evidence only counts if it is in the new text; an exact duplicate in the same thread is not reanalyzed.
The score covers accounts with MRR greater than zero, including those that will leave at the end of the cycle. Internal, test, demo and trial accounts are excluded. Delinquency is not inactivity: a delinquent customer who still has access stays in the base and comes in with the billing signal.
The queue has the account, the severity, a readable reason (which signal fired and when), the MRR at risk, the CS owner and the next action. Sort by severity and MRR. A criterion that fills the queue on its own (for example, just going 30 days without a call) should come out of the OR and become a component.
Record the formula version on each row and, when it changes, keep the original and the recalculated score. Maintain a transitions history (append only, 1 row when an account's severity changes) to count accounts and MRR at risk on any day and measure accuracy.
A customer who cancels shortly after the sale (for example, within 45 days, or 90 days for large accounts) is a sales or implementation problem, not a CS one. Separate that reason so it doesn't mix with portfolio risk.
Risk signals and how much to trust them
Declarations and billing go in directly. Inferences go in only after being tested against real churns.
Definitions
Pitfalls that already happened
In one real base, almost no churn had a recorded usage signal, and those that did were active days before leaving. The usage rule marked most MRR as healthy with no way to contradict it.
Measure each signal against real churns and remove from the verdict anything that doesn't precede cancellation.
More than 80% of email text was repeated history. The AI found the same statements again with every reply and churn signals came out nearly three times higher than reality.
Send only the new text of each email and only accept evidence that is in it.
Even after stripping, about 7% of replies still carried history, because of the Portuguese Outlook header and nested quotes.
Test the markers on a sample and include the Portuguese and nested formats.
Going more than 30 days without a CS call, on its own, put accounts that were doing fine into the queue.
Use contact inactivity as a component, never as a standalone criterion.
Accounts with no usage data showed no risk because the component came through null.
Mark the component as missing data and show it on the account profile.
The formula was adjusted and the risk history started counting something else, with no way to compare.
Record the formula version and the severity transitions history.
Acceptance test
The case is done when every item passes.
- Every active paying account has exactly one row per day, and no internal, test or trial account appears.
- Every account with severity at risk or critical has at least one reason with a date and source.
- Every subscription set not to renew and every open cancellation ticket appears in the queue the next day.
- For the last 3 closed months, alert coverage (churns that were at risk before canceling) is measured and published alongside precision.
- No email evidence used by the score comes from quoted text of a previous message.
Agent package
Paste into Claude, ChatGPT or any client with the Nekt MCP connected.
Health score and churn risk - The universe is paying accounts with MRR > 0, including those that won't renew. Internal, test, demo and trial accounts are excluded. - Risk comes first from declarations and billing: cancellation or downgrade ticket, subscription set not to renew, invoice overdue for more than <N> days, contract expiring within 90 days with no renewal open. - Usage signals only count if they are in the current formula. Don't use usage to say an account is healthy. - The no-alert state means billing up to date and no exit request. Never report it as a percentage of healthy customers. - A component with no data is not an absence of risk. Say the data is missing. - In emails, use only the new text of each message. Text quoted from earlier messages is not evidence. - Always state the reason, the signal date and the MRR at risk for each account. - Early churn (cancellation within <N> days of the sale) is analyzed separately, as a sales or implementation problem. - For questions about the past, use the severity history, not today's table. Per-client exceptions: - <client>: annual contract with <N> days' notice; the notice counts as an exit request. - <client>: account in implementation until <date>, outside the score.
Build the "Health score and churn risk queue by account" case in my Nekt workspace following the rules at https://academy.nekt.com/en/industrias/saas/health-score-risco-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
Components summed into fixed bands (for example, 0 to 12 points in five bands), useful when CS wants to see each signal's weight.
Calls and emails classified by AI into risk, dissatisfaction and opportunity, using only new text and quoted evidence.
Notice and overdue invoice rules combined with a model, auditing the forecast rate against the actual every month.