Your own at-risk rules

sumwerk flags revenue that still counts but is in doubt. Two kinds of signal come from Stripe by themselves: a scheduled cancellation and a failed or overdue payment. The third kind is yours: what you know about a customer. A customer who pays and has not used the product for a month is at risk long before Stripe notices anything.

What you need

One or more attributes on your customers that say whether they use what they pay for: active users in the last 30 days, projects created, a last login. Send them through the API, ideally every night (PUT /api/v1/customers/:id with custom). They show up under Segments the moment the first value arrives.

Find the rule

Open Segments and cut by the attribute. The table shows, per group, the paying customers, their MRR and the churn of the last twelve months. When one row churns several times as often as the others, that row is your rule. Click + rule at the end of the row: the rule form opens filled in.

Write the rule

Account → At-risk rules → Your own rules. A rule has

• a name that people will read on the at-risk list (“Nobody active in 30 days”),
• a level: high, medium or low,
• up to five conditions that must all hold. A condition is an attribute, a comparison and a value: active users, 30 days · is below · 1. Besides your attributes there are owner, plan, billing interval, tags, country, currency, MRR and a few dates.

Comparisons: is, is not, contains, is empty, is set, is above, is at least, is below, is at most, is after, is before, and for dates is more than … days ago and is within the last … days (the value is a number of days).

Two things to know:

• Nothing known is not zero. A customer who does not have the attribute never matches “is below 1”. Use “is empty” if you want to find those.
• All conditions must hold. For “this or that”, write a second rule. At most ten rules.

The rule works at once. Next to it you see how many paying customers and how much MRR it holds for today.

What it does

• Every counted subscription of a matching customer stands on MRR at risk with the rule’s name and level. If the subscription is on the list anyway (a failed payment, a scheduled cancellation), the rule is named next to that reason, the more serious level wins, and the MRR counts once.
• The customer’s page shows it, the CSV and the API carry it (reason: "signal", signals), and so do the Plain card and your AI assistant.
• Nothing changes in your MRR. A flag sits next to the number.

React when a customer starts to match

A customer who starts to match raises the event risk.signal_raised; one who stops, risk.signal_cleared. An automation on “one of your own at-risk rules starts to hold” can give the customer’s owner a task the same hour, or call your webhook.

Customers who matched already when you wrote the rule set nothing in motion: the first run only takes stock. Work through them once, as a list. The same happens again when you change a rule’s conditions.

When a rule does not fit one customer

Some customers use the product in a way the rule does not see. Do not weaken the rule for everyone, and do not remember it every month: on the at-risk list or on the customer’s page, click Not at risk…, say why (“uses the API only, never signs in”) and, if it is temporary, until when. From then on that rule skips that customer. The exception shows on the customer (“Not flagged, on purpose”), under the at-risk list and on the rule, with who set it, and can be removed at any time. What Stripe reports, a failed payment or a cancellation, cannot be excepted.

If you find yourself making the same exception often, the rule is missing a condition: send the attribute that tells those customers apart and add it to the rule.

Through the API

GET /api/v1/risk-rules reads the thresholds and your rules; POST, PATCH and DELETE /api/v1/risk-rules/signals change them with a read-and-write token. See the API reference. Try rules in a sandbox first if you like: it starts with a copy of your live rules.