Open-source churn prediction is four thresholds in a file you own

The score is the easy part. The rule behind it is the thing to buy, and it can be a text file your team reviews.

Churn becomes visible weeks before the cancellation notice arrives: core activity tapers, support threads turn short and angry, a card fails, a renewal date closes in. Four signals, four systems, and nobody reads them together on a Tuesday morning.

Kortix is the open-source CompanyOS. We run a churn-risk scan on it every morning at 06:00, and the scoring rules are a text file in the project repo. That file is the part worth choosing a tool over, because a threshold is a judgment about your customers, and the buying question is who may move it.

What the churn products sell

Pecan AI sells a no-code predictive agent that trains on event history already in a warehouse, Snowflake, BigQuery, Redshift or Databricks, and pushes its predictions into a CRM such as Salesforce (Pecan). Its pricing page names three plans, Starter, Team and Business, and prints no number beside any; a quote arrives after a demo (Pecan pricing). Pendo prices its analytics plans by how many people use them each month, and sells Predict as a module on top, with prediction volume set in the quote (Pendo). Amplitude limits Predictions on its Growth plan and includes them on Enterprise (Amplitude). Gainsight carries Health Scorecards in both of its plans, Essentials and Enterprise, and takes pricing by request (Gainsight). ChurnZero's suite holds ChurnScores, a Renewal Hub and Success Insights that surface machine-learning risk factors (ChurnZero), and churnzero.com/pricing returns a page-not-found, so there is no list price to compare.

Different packaging, same shape: a score computed inside a platform, from the data that reaches it, and delivered to a screen or a CRM field. What a buyer inherits is the part none of the five publishes: the rule behind the score as text you can read before you buy, diff when it changes, or carry to another tool. Where a product lets an admin tune a scorecard, the tuning is a setting, applied to the records that product holds. Ask what the drop threshold is, and the answer is a meeting with an account manager rather than a line in a file. None of the five publishes a self-host option; Pecan will discuss special deployment.

The four signals, and the number that makes each fire

Start with usage: core activity in the last 30 days against the prior 30, per account. A drop of 20% or more against that prior window makes usage a declining signal. Two weeks with almost no activity makes the account dormant. Measure in the unit your product counts, such as events, sessions, active seats or requests, and say which, because the same account can look healthy in sessions and dead in seats.

Support friction comes from the helpdesk. Thread volume is rising when it climbs above that account's own historical rate. The customer base's average is the wrong comparison: a small account that went from three threads a month to five is a change, and a large account steady at forty is not. A thread that stays unresolved past the team's normal first-reply window counts. So does cancellation language, which counts as escalated whatever else the account's numbers say.

Billing turns risky with a missed or failed charge, or a payment method that is removed or lapses with nothing replacing it. A renewal inside the next 30 days counts as imminent. Those four rules and the numbers in them are the whole model.

Why one signal is a hypothesis

No single signal is high risk on its own. An account whose usage dipped 22% might be a seasonal customer. An account whose usage dipped, whose support threads turned, and which renews next month is a different conversation. A single signal is a guess about a customer; the combination is a conversation already under way.

So the ranking puts accounts that combine declining usage, rising support friction, and either an imminent renewal or a failed payment at the top. Everything else is ordered by how many signals fired, then by how close the renewal is. The list is capped at twelve. Twelve accounts is a list people act on; sixty is a dashboard nobody opens.

The scan is three files and a cron line

agents/churn-risk.md holds the agent's job and its one output, skills/churn-signals/SKILL.md holds the four rules and the ranking rule, and kortix.yaml declares the agent, the skill and the schedule. All three come from the churn-risk use case, a setup prompt an agent turns into a change request. This is the trigger, in full:

triggers:
  - slug: daily-churn-scan
    name: Daily churn-risk scan
    on:
      cron: "0 0 6 * * *"
      timezone: UTC
    max_runs_per_day: 1
    overlap: skip
    run:
      agent: churn-risk
      prompt: Load the churn-signals skill and run one complete churn-risk scan.

A cron key takes six fields, seconds first, so 0 0 6 * * * is 06:00 every day (triggers keys). max_runs_per_day: 1 means a retry cannot start a second run. overlap: skip holds a fire while the previous run is still working, which matters because each fire starts a fresh session on its own machine.

A change to a threshold costs a commit. Change the 20% in the skill to whatever number your team agrees on, push a branch, open a change request, and the person who owns customer success reads a diff with the old number and the new one two lines apart. Session work reaches main through a change request. Merge is default-deny for agents. The rule moves when a person moves it, and the repo keeps the reason.

Read-only is a design decision

The agent reads Postgres for usage, Plain for support, Stripe for payment and renewal dates, and writes one message to the customer-success channel. It sends no email, replies to no thread, changes no subscription, and never contacts a customer. Every listed account carries the reason it surfaced, with the measured number, and exactly one suggested next step.

Two things hold that boundary. One isolated sandbox per session. Each session has its own isolated machine and branch. Connector credentials are brokered server-side and never enter the machine.

One run leaves this in the channel. It is our own example run, an illustration rather than a benchmark or a customer result:

Flagged 8 accounts. 2 are highest risk: usage down 34% in 30 days, an escalated support thread, and a renewal in the next 30 days. For both, the suggested next step is a renewal conversation this week.

That shape is a report a person can act on: the measured drop, the reason the account surfaced, the renewal window, one next step. The agent file asks for that register, write like a colleague handing over a list, and never present a score as a fact about a customer's future.

Five questions before you buy a churn tool

• Can I read the scoring rule before I pay? Ask for the thresholds as text, and see whether the answer is a document or a demo call.
• Who can change them, and what does the change leave behind? A setting in someone's console and a commit in your repo answer that differently.
• Where does the run happen? Whose machine, and whose credentials sit in the sandbox at 06:00.
• What lands in the channel? A score per account, or a reason with the measured numbers and one next step per account.
• What does it write back? A read-only report and an agent that can change a subscription are different products with the same marketing.

The caps that make an unattended run safe are in autonomous agents run on a number you set on the trigger. The line between reading and writing gets its own treatment in the refund is where an open-source support agent stops. Both end in the same place: a diff in a change request that someone reads.

The four rules are a starting point. Run the scan for a month, list the accounts that did churn and which signals fired in the weeks before, then change the numbers in the file where a reviewer can see them. Free to start, free to self-host. Try Kortix.