When a CSM is surprised by a non-renewal, the post-mortem almost always surfaces the same observation: "the account seemed fine." The health score was green. The last scheduled call went well. The champion was responsive. And then at renewal, the conversation went sideways and the contract did not close.
What we have learned is that these accounts were not actually quiet. They had patterns in support and email that accumulated over months into a coherent story, but nobody had the time or tooling to synthesize that story before the renewal conversation made it academic. This piece describes three of those patterns specifically: what they look like in the raw data, why they are easy to miss, and what they tend to predict.
Pattern one: the support topic migration
Customers who are deeply embedded in a product and expect to keep using it write support tickets that reflect operational depth. The tickets are about specific workflows, about edge cases in the product they have encountered in realistic use, about integrations they are trying to extend. The framing is almost always forward-looking: "how do I set up X for our upcoming cycle," "is there a way to automate Y for our team."
Customers who are beginning to disengage, even if they are still actively using the product, show a migration in ticket topics. The forward-looking operational questions give way to questions oriented around understanding the scope of their contract, their data, and their options. "What is included in our current plan." "Can we export all historical data in bulk." "How does our billing work if we reduce seats." These questions are individually innocuous. Cumulatively, over a six-to-eight week window, they represent a customer who is reviewing their options rather than deepening their investment.
This pattern is hard to catch manually because each individual ticket is handled as a discrete customer service interaction. The support team answers the question correctly and closes the ticket. No one is aggregating the topics over time against the account's renewal date. The customer gets good service while quietly moving toward the door.
Pattern two: the escalation-then-silence arc
This pattern is counterintuitive when you first see it, which is part of why it gets missed. It starts with a genuine escalation: a customer hits a significant bug, a data loss event, an outage that affected their operations. The support team responds, escalates internally, gets the issue resolved. The account transitions back to normal in the health score. Green again.
What the health score does not capture is what happens in the communication channel after the escalation is marked resolved. Healthy accounts, meaning accounts that accept the resolution and continue their relationship with your product, tend to resume a normal cadence of operational tickets and email after a few weeks. They ask follow-up questions about the fix. They test the repaired functionality and report back. The thread stays alive.
Accounts that are quietly churning after an escalation go silent in a different way. The ticket queue goes quiet not because their operation resumed smoothly but because they have stopped investing in the relationship. The silence is withdrawal, not satisfaction. The support team reads it as resolution. It is actually a kind of giving up.
Distinguishing these two kinds of post-escalation silence requires reading the final messages in the thread and the ticket closure notes, not just the timestamp of the closure. The customer who is satisfied tends to close with something confirmatory: "this seems to be working now, thanks." The customer who has given up tends to close with something flat or noncommittal, or does not close at all and just stops responding. The phrasing is subtle. Over a dozen accounts, it becomes a pattern you can see.
Pattern three: champion communication narrowing
B2B customer relationships have a topology: there are typically a few people at the account who communicate with your team regularly, a wider circle who are copied on important threads, and a broader user population who interact only with the product itself. When a relationship is healthy and growing, the circle tends to widen over time. New people get pulled into threads as the product gets embedded in new workflows. The champion introduces your CSM to other stakeholders. Email distribution lists expand.
The pattern we have seen in accounts that churn quietly is a narrowing of this circle. The email threads that used to include four people now include two. The champion stops copying their manager. Your CSM is no longer being introduced to adjacent teams. The relationship is contracting back toward the minimum viable contact surface, which is often the champion alone managing a relationship that is no longer being evangelized internally.
This is a particularly important signal because it reflects what is happening inside the customer's organization, not just in the communication with your team. When a champion stops bringing new stakeholders into the relationship, it often means the product has stopped being recommended internally. The champion may still like the product personally. They have stopped staking their credibility on it within their organization. That shift in internal advocacy posture tends to precede non-renewal by several months.
It is also a pattern that is essentially invisible in usage data. The champion is still logging in. Their usage metrics look fine. The narrowing is happening in the email header field, in the CC list, in the BCC list your team cannot see but can infer from the absence of others.
Why these patterns compound
These three patterns do not always appear in isolation. In accounts that churn quietly and completely surprise their CSM, what we tend to see is a compound arc: topic migration starts first, typically eight to ten weeks before renewal. Then the escalation-then-silence arc, if there is a triggering incident in that window. Then communication narrowing as the relationship contracts. By the time the renewal conversation happens, all three are present in the historical record, and the CSM is walking into a conversation that the customer has already made up their mind about.
The challenge is that reading this arc requires someone to go back through weeks of tickets and emails, organize them by timeline, and notice the pattern. This is exactly what does not happen in a typical renewal preparation process, which is usually focused on the health score, the usage stats, and the notes from the last QBR. The source material for these patterns exists in the communication record. The synthesis of that material into something actionable does not happen automatically.
What you can do differently
The most direct thing a CS team can do is change what counts as pre-renewal preparation. Instead of or in addition to pulling the health score and usage report, pulling the last 60 days of support tickets and the last 30 days of email threads for accounts renewing in the next 90 days creates the raw material needed to see these patterns. It is time-intensive if done manually. For accounts above a certain ARR threshold, it is worth the time.
Tier-one support should also be aware that their ticket closure choices affect downstream risk assessment. A ticket closed as "resolved" based on a non-response creates a different signal than one closed as "confirmed resolved by customer." The phrasing in closure notes carries information about whether resolution was genuine or abandoned. Building that discipline into support operations requires training and incentive alignment, but it produces a more accurate record.
We are not saying these three patterns appear in every at-risk account. Some accounts churn because of budget, reorganization, or competitive displacement that has nothing to do with communication patterns. What we are saying is that these patterns show up often enough, in accounts that look healthy by conventional measures, that ignoring them is leaving real predictive information on the table. The patterns are not hidden. They are just sitting in the part of the data stack that most CS tooling was not built to read.
