# Churn signals: flag paying customers who stopped using you

By the time Stripe tells you something is wrong, it is late. A failed payment is a customer
who may already have decided. A scheduled cancellation is a decision. The early signal is
somewhere else: **a customer who pays and no longer uses what they pay for.**

## Find the attribute that predicts it

You do not need a data science project. You need one or two numbers per customer that your
product already knows, sent to where your revenue lives: active users in the last 30 days,
projects created, reports run, whatever "using it" means for you. Send them every night.

Then cut the customer base by that number and look at the churn of the last twelve months
per group. In most products one picture appears quickly:

| Active users, 30 days | Paying customers | Churned in 12 months | Churn rate |
|---|---|---|---|
| 0 | 24 | 31 | 56 % |
| 1 to 3 | 61 | 22 | 27 % |
| 4 and more | 64 | 6 | 9 % |

(An invented example; the shape is typical.) The top row is the list to work on: customers
who pay today and will, more likely than not, be gone within a year.

## Turn the row into a rule

A finding that lives in a spreadsheet is forgotten by Friday. Make it a rule that holds
every day: *a paying customer whose active users in 30 days is below 1 is at risk, medium*.
From then on those customers stand in the same list as failed payments and scheduled
cancellations, with the MRR that is in question next to them, counted once even when a
customer is on the list for two reasons.

Two details matter more than they seem:

- **Nothing known is not zero.** A customer for whom the number was never sent must not match
  "below 1". Otherwise every integration gap looks like a churn risk.
- **Dates work too.** "Last login more than 14 days ago" is often a better rule than a count,
  because it does not depend on the size of the customer.

## Act on the change, not on the list

A list of 24 accounts is a project. One account that *starts* to match is a task. Have the
rule raise an event when a customer begins to match, and let it create a task for the
customer's owner the same hour: "Usage dropped to zero: call before the renewal." The
customers who already matched when you wrote the rule should not set anything in motion;
work through them once, as a list.

## Check whether it works

After a quarter, look at the same table again. If the churn rate of the flagged group has
not moved, the outreach does not work, or the signal comes too late, and you need an earlier
one. If the group got smaller because customers moved down into the healthy rows, you have
found the cheapest retention programme there is.

In sumwerk this is three steps: send the attribute through the API, open Segments and click
"+ rule" on the row, and add an automation on "one of your own at-risk rules starts to hold".