You don't know a customer is going to churn until they already have.
That's the dirty truth about most SaaS retention dashboards. You log in on a Monday, see the MRR chart dipped, click into the churned accounts list, and start doing forensics on decisions that were made weeks ago. The customer filed four support tickets about a broken CSV export. They hadn't logged in for 19 days. They were using two features out of the eight they signed up for.
All of that was visible in your database the entire time. Nobody was watching.
The problem isn't the data. It's that churn is being treated as a metric when it's actually a lagging indicator — a record of failure, not a signal you can act on. By the time "churned" appears in a row in your customer table, the decision was made long before the cancellation email arrived.
This article is about building a system that watches the signals you're currently ignoring, scores them automatically, and tells you who's at risk and why — before they've decided anything.
#The Three Signals That Precede Churn by 2–4 Weeks
There's a pattern across SaaS churn that's consistent enough to be useful. It's not universal, but it holds for the majority of involuntary disengagement cases.
Signal 1: Login frequency drops below 50% of baseline. If a customer was logging in 4 days a week and now they're logging in once a week, something changed. Maybe the product stopped solving the problem. Maybe they found an alternative. Maybe they got promoted and the person who used to care about your tool is now someone else entirely. Whatever the cause, the login drop almost always precedes cancellation by 2–4 weeks.
Signal 2: Support ticket volume spikes — especially repeat topics. One support ticket isn't a signal. Two tickets about the same issue in 14 days is a yellow flag. Three tickets, same issue, no resolution, is someone drafting their cancellation email.
The pattern is specific: it's not that frustrated customers submit more tickets in general — it's that they submit escalating tickets on the same unresolved thread. A customer who files "CSV export broken" on April 7, then "CSV export still broken" on April 14, and hasn't logged in since April 18 is gone unless you personally call them.
Signal 3: Feature usage narrows. Customers who are disengaging start using fewer features. They were using your reporting module, your integrations tab, and your team management tools. Now they're only opening the core feature — the minimum viable usage before they cancel.
This one is easy to miss in aggregate metrics. Cohort-level feature adoption looks fine. But at the individual account level, a customer who's dropped from 6 active features to 2 over 30 days is disengaging, not just having a slow week.
None of these signals alone is a reason to panic. Two of them together on the same account? That's a Slack notification. All three? That's a phone call.
#Building the Churn Detection Agent
The architecture here is the same general structure as the Financial Analyst Agent — a scheduled workflow that pulls data, runs it through an LLM for analysis, and routes results to wherever you'll actually act on them. The difference is this one runs on your product usage database instead of Stripe.
Here's the blueprint.
#The nightly trigger
Set a Make.com or n8n workflow to fire at 6 AM every day. The first step queries your product database (via direct database connection, Supabase API, or a middleware analytics tool like Mixpanel or PostHog) for all active paying accounts.
For each account, pull three numbers:
- Login count in the last 14 days vs. the 30-day prior period
- Support ticket count in the last 30 days, grouped by unique issue thread
- Number of distinct features with at least one event in the last 14 days vs. 30 days prior
This gives you three ratios per account. Run them through a simple scoring function — you don't need an LLM for this part, and you shouldn't use one. This is deterministic math. An LLM is excellent at reasoning; it's bad at arithmetic. Do the calculation with logic nodes, not a model.
A simple scoring approach: 1 point for each signal that crosses its threshold (login < 50% of baseline, support tickets > 2 on same topic, active features down > 30%). Accounts scoring 2 or 3 get flagged for the next step.
#The LLM analysis step
A score tells you who. You need Claude to tell you why.
For each flagged account, build a structured context object: account name, account age, plan tier, the three signal values, the support ticket subjects, and the last 5 feature events. Pass this to Claude with a system prompt that looks roughly like:
"You are analyzing a SaaS customer account for churn risk. Based on the behavioral data provided, write one sentence that states the most likely reason this customer is disengaging. Be specific. Do not hedge. Output format: '[Account Name] appears to be disengaging because [specific hypothesis].'"
The output you get back looks like:
- "Acme Corp appears to be disengaging because their primary use case — CSV data exports — has been broken for 21 days with no resolution."
- "Greenfield Labs appears to be disengaging because the team member who championed the product (Sarah, last login March 12) has likely left the company."
- "Trident Digital appears to be disengaging because they've narrowed usage to the core feature only, suggesting the integration workflow they purchased for is not being used."
That's actionable in a way a churn score isn't. The score says "at risk." The hypothesis tells you what to do next.
#Routing to where you'll actually act
The final step sends flagged accounts to a dedicated #churn-risk Slack channel with the account name, score, ARR, and the one-sentence hypothesis. Format it so it's scannable in 10 seconds per account.
Don't send the raw data. Send the decision. The message should read: "Acme Corp [Score: 3/3 · $1,400/mo]: Has been disengaging for 21 days. Hypothesis: unresolved CSV export bug. Recommended action: personal outreach + engineering escalation."
Recommended action is worth including. The LLM can generate it based on the hypothesis type — but set specific rules in the prompt for what maps to what.
#The Intervention Playbook
Not every at-risk account gets the same response. The intervention should match the hypothesis.
Unresolved bug or product failure → Personal call or email from the founder. Not a support ticket. Not an automated check-in. A founder-to-customer message that acknowledges the problem by name and commits to a specific resolution timeline. This is the only intervention that works when someone is frustrated with a broken product feature.
Feature adoption gap → A short 15-minute call framed as a check-in, not a save attempt. The goal is to understand whether the use case they purchased for is still relevant and whether there are features they haven't discovered. Don't pitch. Ask questions. Honestly — a lot of these calls reveal that the customer bought for a use case that no longer applies, and the right move is to help them find a better fit, not fight the churn.
Champion has left → This is the most under-noticed churn pattern. When the person who bought your product leaves a company, their replacement has no attachment to your tool and will cut it at their first budget review. The intervention is proactive: reach out to the new stakeholder immediately, reintroduce the product, and if possible, offer a 60-minute onboarding session specifically for their role.
Usage narrowing without a clear hypothesis → A proactive NPS survey sent from the founder's email address. One question: "What would need to change for [Product] to become more valuable to your team?" You get either an answer you can act on, or you learn the account is already mentally gone.
#The Failed Payment Early Warning System
Involuntary churn — customers who want to stay but whose payment fails — accounts for 20–40% of total SaaS churn at most companies. And it's the most preventable category.
Stripe's default behavior is to retry the failed payment 3–4 times over 2 weeks, then cancel the subscription. Most founders let this run on autopilot and only notice when the account shows up in the churned list.
Don't do that.
Set a Stripe webhook that fires the moment a payment fails — not after the retry cycle. The webhook should trigger a single, plain-text email from your personal email address (not your newsletter tool, not a transactional email template with your logo) that reads something like:
"Hey [Name] — I noticed your payment for [Product] didn't go through this morning. Wanted to flag it personally before anything gets suspended. If it's a card issue, you can update your billing details here: [link]. If something else is going on, just reply to this email."
That email, sent within 2 hours of the failed payment, recovers a significant portion of involuntary churn on the spot. The customer didn't know their card expired. They weren't about to churn. You just caught a billing friction point before Stripe's dunning cycle turned it into a cancellation.
The 72-hour window between first failed payment and subscription suspension is your intervention window. Most founders waste it by letting Stripe handle it. You shouldn't.
Build the nightly agent first — that's the part that surfaces the problems. The intervention playbook only works if you know who to call. And right now, the customers who are 3 weeks away from canceling are invisible in your dashboard, sitting at a score of zero while their login frequency quietly halves week over week.
The cancellation email isn't the problem. It's just the notification that the problem went undetected for too long.