Ask ten RevOps or CS leaders when churn is "decided" and you'll get answers ranging from "when they tell us they're not renewing" to "when they stop responding to emails" to "the day their champion left." These are all true to some degree, but they're all too late. In B2B SaaS, the decision to churn is rarely made at the moment it's communicated. It accumulates over months, and the signal pattern is legible — if you're looking at the right data, at the right resolution.
The useful question isn't "when did this account decide to churn." It's "when is the last point at which an intervention would have had a realistic chance of changing the outcome." That's the window that matters operationally, and it's almost always 60-90 days before the renewal conversation, not 14 days.
The Anatomy of a B2B SaaS Churn Event
Churn in B2B SaaS almost never happens because a customer woke up one morning and decided to leave. It happens because a slow-moving sequence of smaller failures accumulates to the point where the ROI calculation stops working for the customer, and by the time the renewal conversation arrives, they've already mentally decided the answer is no.
The typical sequence looks something like this. Month 1-3 post-onboarding: initial adoption enthusiasm, high support engagement, good login frequency as users figure out the product. Month 4-8: usage patterns stabilize. For accounts that will eventually churn, this is often when usage starts to plateau at a level below what the account initially hoped for — core workflows adopted but secondary use cases never activated, the "next phase" of the implementation that never quite happened.
Month 9-15 (in an annual contract): the soft disengagement begins. The champion is less responsive to CS outreach. Login frequency declines gradually. Feature exploration stops. New user activations within the account slow or stop. The product is still running, still being used by the original users, but the account's relationship with it has become maintenance rather than growth.
Month 16-18: the renewal conversation is now 90-60 days out. By this point, the internal narrative at the customer is usually already formed. Someone has asked "are we getting value from this" and the answer has been uncomfortable. The competitor has been evaluated, or at least mentioned. The budget owner is asking whether this line item survives the next planning cycle.
At the 30-day mark, the account team calls to "start the renewal conversation." The customer is polite. They ask for pricing flexibility. They mention they're evaluating options. The CS manager scrambles for an executive sponsor escalation. The probability of a successful outcome from this point is low — not zero, but substantially lower than if the same energy had been invested 90 days earlier.
When Product Signals Appear Relative to Churn
The question of signal timing is empirically answerable if you have product usage data on churned accounts. When we looked back at churned accounts in historical data, the pattern was consistent enough to be instructive. The product usage signals that we now track — DAU/MAU ratio, core feature event volume, API call frequency where applicable — showed meaningful degradation an average of 75-90 days before the renewal date on accounts that ultimately churned.
The specific pattern wasn't always a dramatic cliff. In many cases, the decline was gradual — a 5-10% month-over-month reduction in core feature engagement starting four to five months before renewal. Viewed in isolation, any single month's decline looked like noise. Viewed as a trend over four months, it was a reliable indicator. This is why point-in-time health scores are less useful than trend-based signals. An account at 60% of its peak DAU/MAU is not necessarily at risk; an account that was at 85% six months ago and is now at 60% and still declining is a different story entirely.
The steepest signal drops typically appeared in the 60-75 day pre-renewal window. At this point, accounts that were going to churn had often crossed an internal threshold — the renewal budget review had happened, the competitive evaluation was underway, or a key champion had changed roles. Once these events occur, the product signals often drop sharply because the organizational motivation to engage with the product has collapsed.
Why 90 Days Is the Practical Intervention Threshold
Given that signals typically become meaningful 75-90 days out, and given what's possible in a CS intervention, 90 days is the right threshold to trigger action — not 30, not even 60.
Here's why the lead time matters so much. A productive churn intervention isn't just a phone call to check in. It requires diagnosis: understanding why engagement has declined, which use cases didn't land, whether there are product gaps or onboarding debt or a champion access problem. That diagnosis takes a conversation or two. Then it requires an action: a feature walkthrough, a re-onboarding session, an executive sponsor introduction, a custom success plan, sometimes a product change request. Each of those actions takes time to schedule and execute. And then the response to that intervention — whether the customer's behavior actually changes — takes several weeks to manifest in the usage data.
If you're starting this process at 30 days to renewal, you don't have time for a proper diagnosis phase. You're in reactive mode from the first call. At 90 days, you have time to run the full cycle: diagnose, intervene, observe the response, and if the first intervention doesn't work, try a different approach before the renewal deadline arrives.
A reasonable target for a CS team with good churn signal tooling is to have zero accounts entering the 45-day pre-renewal window as uncontacted risk flags. If an account is flagging as at-risk, it should have been in active intervention for six weeks already. The 45-day window should be for accounts that are on track, not for discovering that an account is disengaged.
The Champion Change Problem
One signal category that deserves its own discussion is champion change. In B2B SaaS, losing the internal champion who drove the purchase is one of the highest-risk events for retention. When a champion changes roles or leaves the company, the product often loses its internal advocate — the person who knew its value, trained others on it, and justified the budget. New decision-makers who didn't select the tool are much more likely to re-evaluate it at renewal.
Champion change is hard to detect from product data alone. The signal that's most accessible is a sudden login pattern change from a historically high-usage user — an account's top user going from daily login to infrequent login to no login is often a champion departure signal worth investigating. Pairing this with LinkedIn monitoring (if your CS team has the bandwidth) or CRM contact activity monitoring catches more cases, but the signal is inherently hard to detect early.
We're not saying you'll catch every champion change before it affects the renewal. Champion changes are often genuinely sudden. What you can do is ensure that for your highest-ARR accounts, you have at least two internal champions mapped — your primary contact and a secondary stakeholder — so that a single champion departure doesn't leave you flying blind in the account.
Building a Signal Decay Model
The most practically useful churn signal framework is a decay model: rather than asking "is this account healthy right now," ask "is this account's engagement trending in the wrong direction, and for how long?" A decay function that weights recent engagement decline more heavily than longer-term historical engagement gives you a dynamic risk score that responds to emerging patterns rather than just comparing to a static baseline.
The technical implementation is straightforward: compute a rolling 30-day average of your core engagement signal, compare it to the prior 90-day average for the same account, and flag accounts where the ratio has dropped below a threshold (say, 0.75) and has been declining for at least 45 days. Accounts that clear this threshold and are within 120 days of renewal go into the active intervention queue.
What changes operationally when you have this running is that your CS team's weekly priorities become model-derived rather than relationship-derived. The question isn't "which accounts do I feel worried about this week" — it's "which accounts does the model say are in the decay pattern with enough lead time to intervene." These are not always the same accounts. The ones you feel worried about are often the ones that have been squeaky wheels. The ones the model flags are sometimes accounts that haven't made any noise yet and are about to become a problem.
Churn rarely surprises the data. It's already there in the logs, fading slowly toward the renewal date. The question is just whether anyone is looking at the right time series, at the right level of resolution, before it's too late to do anything about it.