# Open-source churn risk scoring a customer-success lead can argue with

> Churn risk scoring turns readings from usage, support and billing into one ranked list, and each threshold behind the rank has to be one a person can defend. Kortix is the open-source CompanyOS: your agents, their skills, your company memory, and every connector in one git repo you own, with the agents working on real cloud computers.

URL: https://churnpredictionguide.com/churn-risk-scoring

## The five lines that turn readings into a rank

`skills/churn-signals/SKILL.md`

```
- Usage is declining when core activity drops 20% or more against the prior 30 days, and dormant after 14 days with almost no activity.
- Support friction is rising when thread volume climbs above the account's history or threads stay unresolved. Cancellation language counts as escalated.
- Billing is at risk after a missed or failed payment. A renewal is imminent within 30 days.
- No single signal is high risk on its own. Rank accounts with declining usage, rising support friction and an imminent renewal or failed payment first.
- Give every listed account a reason and one next step. Never write to Postgres, Plain or Stripe, and never contact a customer.
```

Source: https://kortix.com/use-cases/churn-risk

The churn-signals rule set as the churn-risk setup holds it, with each threshold and the combination rule in the words the agent loads before a scan.

## A churn risk score is a rank a person can check

Churn risk scoring reads product usage, support and billing, then orders the accounts with the worst combination at the top of a list. A churn risk score is the place an account holds in that order. It is only useful when the readings that produced it travel with it. A customer-success lead works down from the top because the worst cases are there; the figure beside each name orders the list, and the readings are what the lead argues with. Someone who can see why an account reached the top either makes the call or finds the rule that put it there wrongly, and both outcomes move the account.

Compression is where most scores lose the reader. A health score inside a customer-success tool turns one feed of data into a number between 0 and 100. The person reading it has to guess which reading moved. A fitted model returns a probability and, at best, an ordered list of the features it weighted. Both are defensible engineering. Neither answers the Monday question cleanly: why is this account above that one, and what should happen next?

The churn-signals skill in the [Kortix](https://kortix.com/use-cases/churn-risk) churn-risk setup runs on five lines. Four describe a reading and the threshold that turns it into a signal. The fifth fixes the combination, the reason carried with each account, and the next step. Read as a set, they answer the Monday question before anyone has to ask it.

## Where each threshold sits, and the reason behind it

Usage carries two readings, and the 20% rule is the one teams debate first. Core activity falling 20% or more against the prior 30 days counts as declining. The comparison is the account's own previous month rather than an average across the book. That choice matters more than the number does. A small account and a very large one are held to the same relative move, and a team whose use is naturally spiky is not scored against a calmer neighbor. A fall that size across a full month is also harder to produce by accident than a quiet week. The line sits at 20% rather than at a single day's dip for that reason.

Dormancy is the second usage reading: 14 days with almost no activity. It is the earliest signal in the set and the most likely to be wrong. A single quiet week can be a holiday, a shutdown, or a team that finished the project it bought the product for. Two full work weeks is a pattern rather than an absence, which is the point of the fortnight. Dormancy says someone should look. It never says someone should call.

Support friction has three parts, and they measure different things. Thread volume climbing above the account's own history measures strain. Threads that stay unresolved measure whether the strain is meeting help. Cancellation language counts as escalated, and it is the only reading in the whole rule set that states the outcome in words.

Billing carries a missed or failed payment and a renewal inside 30 days. The payment record comes from a system that tracks money rather than behavior. It fails for reasons the other two never produce: a card that expired, a treasury hold, a purchase order that arrived late. The renewal date is the one reading with a deadline attached. Inside 30 days, a conversation still changes the outcome. At 90, it mostly records one.

## The combination rule does the sorting

No single signal is high risk on its own. The rule exists because each reading fails for its own reasons, and those reasons do not line up. A seasonal dip in the product database has nothing to do with a reissued credit card. A support queue that sat on a simple question has nothing to do with either. One rule firing is a modest reason to look. Three firing in the same month require every system to be wrong at once.

Ranking follows the same logic. Accounts with declining usage, rising support friction and an imminent renewal or failed payment go first. That combination is the closest thing the data holds to a team on its way out. Accounts with one or two readings earn a place further down the list, where the cost of checking is small and the cost of ignoring is a surprise at renewal.

## One account through the rules

Acme carries a usage decline of 26% against its own prior 30 days, two support threads unresolved for six days, and a renewal 22 days out. Three of the four rules fire, so Acme ranks highest. Each reading is small on its own: six points past the 20% line, two threads six days old, a renewal still three weeks away. Its reason line states what the rules found, in the order a person can check: usage down 26%, two unresolved threads, renewal in 22 days. The next step is a renewal conversation this week.

Globex shows how the sorting holds a single reading back. Its usage is flat and one thread sits unresolved, with no payment problem and a renewal eight months away. One rule fires, so Globex stays on a watch list and costs nobody a call. Northwind has been dormant for 16 days with nothing else behind it, which is the most common false positive in the set. It stays off the list for the same reason.

Acme, Globex and Northwind are placeholders and their figures are illustration, not a result from Kortix, a customer, or a benchmark.

## The monthly review, and how a threshold moves

A rule set drifts out of date quietly. The account mix shifts, a pricing change moves what counts as heavy use, and a threshold that was right in January flags the wrong half of the book by June. The review that keeps it honest takes an afternoon a month. It runs backwards from the outcome rather than forwards from the score.

Take the accounts that churned in the quarter and look at the readings in the 30 to 45 days before each one left. Count, per rule, how many churned accounts it caught. Count the same rule against the accounts that stayed. The second column is the one teams skip, and it is the one that decides whether a rule is a signal or a habit. A rule that fires on most churned accounts and on most surviving ones tells you nothing about either group. A rule that fires on few churned accounts is not worth its noise. The interesting line in between is where a threshold moves.

Change one threshold at a time, write down the reason beside it, and date the change. A threshold carried by a comment somebody can read six months later is worth more than a smarter one nobody can explain. Then run the scan against the same week's data the old rules scored. The movement is visible and attributable that way, rather than inferred from a feeling that the list got better.

A threshold is a line in `skills/churn-signals/SKILL.md`, so changing it is a change to a file rather than a support ticket to a vendor. On Kortix that edit arrives as a change request, reviewed like any other work before the next 06:00 run. Approval gates you set. Off until you set them. Hand it an outcome; agents plan the work, run it on their own computers at any hour, get it checked by a separate agent and a change request, and learn from it.

## What a score must never do

A churn score must never contact a customer, and that boundary is what keeps a wrong threshold cheap. An agent that emails the at-risk account when its confidence passes a line turns every false positive into an incident. A team that has apologized twice stops trusting the list. The connectors into Postgres, Plain and Stripe are read-only in this setup. The scan reads Postgres, Plain and Stripe and writes one message to the team channel, so the worst outcome of a bad rule is a call nobody needed.

The second prohibition is a change to an account. A score that can alter a subscription, close a ticket, or pause a plan has taken a decision away from the person who owns the relationship. It will eventually act on a misread. The score's job ends at the reason.

The third prohibition is the easy one to drop: a score must never arrive without its reason. A rank with no readings behind it cannot be checked, and an uncheckable rank stops being read. The reason is what lets the account owner disagree with the system. The disagreement is the fastest way to find the threshold that is wrong.

## When a trained model earns its place

A fitted model needs history the rule set does not have yet: a table of accounts that churned, with their usage, support and billing readings from the weeks before each departure. Several review cycles produce that table. Once it exists, a model can weigh combinations a person would not write by hand, such as a seat count that grew while usage flattened, and it can score the long tail of accounts that never trip a hard rule. The rule set should stay when the model arrives, because the two do different jobs. The model orders accounts inside the group the rules already flagged. The rules keep producing the reason and the next step that make the list usable. A model that replaces both leaves a team with a probability and no sentence to act on. A book of forty accounts does not need either, since the person who speaks to each one every quarter already knows more than the ranking does.

## Churn risk scoring, answered

### How is churn risk scored?

Churn risk scoring compares each account against fixed rules on usage, support and billing, then ranks the accounts where several rules fire in the same window. In the churn-signals rule set, usage counts as declining when core activity drops 20% or more against the prior 30 days.

### What is a churn risk score?

A churn risk score is an account's place on a short list ordered by how many independent churn signals fired for it, with the readings behind each signal attached. It sorts who to call first, and it says nothing certain about any single account.

### What thresholds should a churn score use?

Start with thresholds a person can check and defend: a 20% drop in core activity against the prior 30 days, 14 days of near-inactivity, unresolved support threads, a failed payment, and a renewal inside 30 days. Then move one at a time, from what the churned accounts show.
