A B2B SaaS company with 200 active accounts had never predicted a churned customer. Not because the company lacked customer data — it had usage logs, support ticket history, contract records, and NPS scores. It lacked the operational architecture to translate that data into a signal visible before the cancellation notice arrived. Customers who churned had uniformly shown warning signs six to eight weeks before cancellation — declining usage, unresolved support issues, unanswered QBR scheduling requests — that the customer success team had not been systematically monitoring. The seven-month engagement produced a customer health architecture and a structured CS operations process that reduced annual churn from 18 percent to 11 percent in the twelve months following implementation.
The company had grown from twenty to two hundred accounts over three years and had not rebuilt its customer success operations to match the scale. At twenty accounts, the founder and two account managers knew every customer personally, called them regularly, and could sense impending problems through relationship proximity. At two hundred accounts, the same relationship-proximity model required ten times the attention bandwidth, which the team did not have. The model had not been redesigned; it had been stretched until it no longer worked reliably.
The challenge: design a customer success operations architecture that could systematically surface account health signals across 200 accounts without requiring account managers to hold the status of every account in their heads, and build the processes by which those signals could be acted on before customers reached the cancellation decision.
Starting Conditions
The company sold a mid-market project management SaaS with an average contract value of $28,000 annually and an average contract length of eighteen months. Customer success was handled by a team of four — one customer success manager (CSM) and three account managers (AMs), each managing between forty-five and sixty accounts. The company had a 90-day onboarding process that it tracked systematically; post-onboarding account management was unstructured.
Customer data available but not integrated. Usage data from the product analytics platform — logins, feature usage, active user counts — was available to the product team but not to the CS team. Support ticket history was in the support platform, accessible to the CS team but not linked to account health metrics. NPS surveys were sent annually and results stored in a spreadsheet. Contract terms and renewal dates were in the CRM. The four data sources were not connected; seeing a complete picture of any single account required opening four systems and assembling the picture manually.
Account management by attention rather than signal. AMs managed their account portfolios by memory and by the frequency of inbound customer contact. Accounts that contacted the company regularly received regular attention. Accounts that did not contact the company were assumed to be healthy — the absence of complaint was interpreted as a positive signal. This is systematically wrong in B2B SaaS: the customers most at risk of churning are often the ones who have stopped engaging with the product and stopped contacting support, because they have mentally exited the relationship before formally exiting the contract.
Reactive support pattern. The CS team's primary mode was reactive — responding to inbound questions, handling escalations, processing renewal paperwork. Proactive outreach existed in principle: QBRs were supposed to happen quarterly. In practice, QBRs happened when customers requested them or when AMs had capacity after handling inbound volume. For accounts that never requested QBRs and generated little inbound contact, proactive outreach happened rarely or not at all.
Churn postmortem data. The company had churned thirty-one accounts in the prior year — a rate of approximately 18 percent. Postmortem analysis of those thirty-one accounts revealed a consistent pattern: all had shown at least two of four early warning indicators in the sixty days before cancellation. The indicators were: login frequency decline of more than 40 percent from their personal baseline, active user count decline of more than 30 percent, at least one support ticket unresolved for more than fourteen days, and missed QBR for two consecutive quarters. The indicators had been visible in the data; no one had been systematically reading them.
Structural Diagnosis
Three structural problems explained why eighteen percent annual churn was happening despite available data that could have predicted it.
Health data siloed from operational workflow. The four data sources that together constituted account health — usage analytics, support history, NPS, contract terms — were in four separate systems with no integration. An AM who wanted to know the health of one account could assemble the picture in fifteen minutes. An AM managing fifty-five accounts could not do that for every account every week; the time cost was prohibitive. When health monitoring is expensive per-account, it happens only for accounts that are actively demanding attention — which is precisely the wrong set of accounts to monitor, because they are already engaged.
Conventional fixes — dashboards that surface account health — fail unless the dashboard is integrated into the AM's daily operational workflow rather than requiring the AM to navigate to it. A health dashboard that exists but must be sought produces health monitoring for accounts the AM is already thinking about. The structural fix required integrating health signals into the workflow that AMs already used every day.
No baseline, no deviation. The churn postmortems showed that the warning indicators were relative — a login decline of 40 percent from baseline, not an absolute login count. Without baselines, AMs had no way to distinguish declining accounts from accounts that had always used the product lightly. An account with ten logins per week that dropped to four was different from an account that had always had four logins per week, but both looked similar in absolute terms. Building a health signal required first establishing per-account baselines and then tracking deviation from baseline — a capability the company did not have because usage data had been captured as absolute counts rather than as percent-of-baseline measures.
Proactive outreach governed by capacity rather than signal. The CS team's proactive outreach calendar was driven by availability — QBRs were scheduled when AMs had time. This produces a distribution of attention that is orthogonal to risk: busy periods, when AMs have less time for proactive outreach, are also typically the periods when renewals are concentrated, which is when at-risk accounts most need attention. A proactive outreach cadence governed by risk — accounts in health decline get outreach prioritized regardless of AM capacity — requires a health signal that is systematically produced and a process that acts on the signal before capacity considerations.
The Intervention
Seven months. The sequence was determined by data dependency — you cannot build a health signal before you have established baselines, and you cannot design operational processes around a health signal before the signal exists and has been validated against historical data.
Phase 1: Data Integration and Baseline Establishment (Months 1-3)
What was built: A customer health data layer integrating the four existing data sources — usage analytics, support history, NPS, and CRM — into a unified account view accessible within the CRM each AM already used. Usage data was pulled via API and displayed within each account record. Per-account baselines were calculated from the first twelve weeks of post-onboarding data for each account — the period when each customer settled into their usage pattern. Deviation from baseline was calculated weekly and displayed as a health indicator rather than as a raw count.
Why this came first: The health signal was the foundation on which all operational redesign depended. Building operational processes around a health signal that did not yet exist would have produced processes that specified how to respond to signals without establishing what the signals were. Historical data from the prior eighteen months was used to validate the four warning indicators identified in the churn postmortems — confirming that the indicators predicted churn at a rate sufficient to be operationally useful before the team was asked to change their workflow in response to them.
The mechanism: Baseline deviation as a health metric is more sensitive than absolute usage as a health metric because it accounts for product adoption variation across accounts. An account in health decline looks different from a low-adoption account when measured against its own baseline; it looks identical when measured against an absolute threshold. The specificity of baseline deviation — identifying accounts that are departing from their own established pattern — is the mechanism that makes the signal actionable rather than noisy.
Phase 2: Customer Health Scoring and Operational Integration (Months 2-5)
What was built: A customer health score combining the four warning indicators into a weighted composite, displayed in the CRM with a traffic-light system: green (no indicators triggered), yellow (one or two indicators triggered), red (three or four indicators triggered). The score was recalculated weekly from updated data. A portfolio view showing all fifty-five accounts for each AM with their current health scores, sortable by health and by renewal date. An automated alert that created a task in the AM's task queue when an account transitioned from green to yellow, or from yellow to red.
Why this depended on Phase 1: The health scoring required the integrated data layer from Phase 1 and the validated indicator weights. Scoring built on unvalidated indicators would have produced a score that felt credible but did not predict the outcome it was designed to predict.
What this unlocked: AMs could manage their portfolios by exception — reviewing red and yellow accounts daily, green accounts on a defined review cadence — rather than by memory. The AM's daily workflow started with a portfolio health view rather than with an inbox. Accounts in health decline received attention based on their health signal rather than based on whether they were generating inbound contact.
Phase 3: Proactive Outreach Process Design (Months 4-7)
What was built: A structured proactive outreach process organized by health tier. Red-tier accounts received a mandatory outreach within forty-eight hours of flagging — a structured check-in call with a defined agenda: product usage questions, support issue review, success plan confirmation. Yellow-tier accounts received a scheduled outreach within seven days. Green-tier accounts received a monthly touchpoint on a defined schedule regardless of inbound contact. QBRs were scheduled based on contract value and health tier rather than based on AM availability — high-value accounts got quarterly reviews regardless of capacity, with backup coverage from the CS manager when individual AM calendars were full.
Constraint introduced: The mandatory outreach protocol required AMs to conduct outreach even when they were confident an account was fine — the protocol did not allow for the AM's judgment to override the health signal during the first six months of implementation. This constraint was uncomfortable for experienced AMs who trusted their relationship knowledge more than the data. The constraint was correct: in the first six months, four of the eight mandatory outreach calls to accounts AMs would have left alone produced material account health information that the AM had not known, including two accounts that were evaluating competitive alternatives.
Results
Annual churn reduced from 18 percent to 11 percent. In the twelve months following full implementation, twenty-two accounts churned versus thirty-one in the prior year. The reduction was concentrated in accounts that had received early-warning outreach — accounts flagged as yellow or red and contacted within the defined windows churned at half the rate of accounts flagged late or not contacted before cancellation.
Eight at-risk accounts recovered. Eight accounts that entered the red health tier and received structured outreach within forty-eight hours were retained through the following renewal cycle. The outreach identified specific product adoption gaps in five of the eight cases and unresolved support issues in three. Resolution of those specific issues, tracked to completion by the AM, produced recoveries that would not have occurred without the structured protocol.
Average QBR completion rate: 91 percent. The prior year QBR completion rate had been approximately 55 percent. The structured scheduling protocol — QBRs calendared in advance with defined AM responsibility and CS manager backup — produced a 91 percent completion rate. The nine percent that did not complete were accounts that had churned before the QBR window.
AMs reported reduced cognitive load. The portfolio view with health scores reduced the mental overhead of managing fifty-five accounts simultaneously. AMs reported spending less time wondering whether they were missing something important — the health signal provided the answer. This is a soft outcome but an operationally relevant one: cognitive load reduction translates to capacity for higher-quality attention on the accounts that most needed it.
Counterfactual. At 18 percent annual churn, the company needed to acquire 36 new accounts per year just to maintain its 200-account base, before accounting for growth. At 11 percent churn, the acquisition requirement dropped to 22. The seven-point churn reduction was equivalent to eliminating the acquisition cost of approximately 14 accounts annually — at the company's average contract value of $28,000, a $392,000 annual acquisition cost reduction, before counting the revenue from retaining accounts that would otherwise have churned.
The Transferable Lesson
The company did not have a customer relationship problem. It had a signal architecture problem — its operational system was designed to respond to inbound customer contact rather than to produce outbound health signals.
The diagnostic pattern: when churn is always a surprise, the organization's customer success model is reactive. Reactive CS models work at small scale because relationship proximity provides the early warning signal that systematic monitoring would provide at larger scale. The warning sign that a reactive model has been stretched beyond its effective range is not high churn — it is high churn combined with the observation, in postmortem analysis, that the warning signals were present in existing data and not acted on. That combination means the data was there and the process to act on it was not.
The design principle: build health signals before building the processes that act on them. A proactive outreach process without a health signal is a calendar. A health signal without a proactive outreach process is a dashboard. The combination — a health signal integrated into the operational workflow and a process that responds to the signal on a defined schedule — is what produces the outcome. The sequence in which those components are built is not interchangeable.