Before we built Sturdy, I spent several years in customer success leadership. One of the regular rituals of that job was reviewing the quarterly NPS results, sorting accounts by score, and triaging the detractors. Every quarter, there would be a handful of accounts that sent low scores and a handful that had already churned without ever sending a low score at all. The churned-without-warning ones were always the ones that stayed with me.
When I looked back at the account history for those quiet churns, the frustration was always there. It was in the tickets. It was in the tone of the email threads. The customer had expressed what they needed to express in their support interactions, and nobody had been reading those interactions as a whole. We had been waiting for the survey to tell us something the tickets had already said.
That observation was the starting point for building Sturdy.
The structural problem with surveys as a feedback mechanism
Surveys are not a bad product. They are a useful tool for measuring aggregated opinion at a point in time. The problem is that they are used for a purpose they were not designed for: detecting individual account risk in real time.
The timing issue alone disqualifies surveys for renewal risk detection. A quarterly NPS or CSAT survey is sent on a schedule, which means the data is already at least a few weeks old when it arrives. More importantly, surveys reach customers who have already formed a complete opinion. By the time someone fills in a low NPS score, they have usually been frustrated for a while. The decision may already be made. The survey is documenting a condition that existed before the survey was sent.
The response rate problem compounds this. Most B2B NPS programs see response rates in the 20 to 35 percent range when run well. That means you are not hearing from the majority of your customers. The silent majority contains both your most satisfied accounts and your highest-risk ones. There is no reliable way to know which a non-responder is.
The third issue is one that anyone who has designed a B2B survey program has encountered: customers give artificially inflated scores to avoid a CS follow-up call. The professional courtesy norm in B2B relationships means that a customer who gives a 4 or 5 out of 10 knows they will receive a call. Some percentage of customers will give a 7 to avoid that call, even when their actual sentiment is lower. The survey result is not measuring what they feel. It is measuring what they are willing to report.
What tickets record that surveys do not
A support ticket is written at the moment of frustration, not two weeks afterward. The customer files the ticket because something is not working right now, or at least within the last few hours. That immediacy means the language in the ticket reflects the customer's actual emotional state in a way that a retrospective survey cannot.
More importantly, tickets are written when the customer has not yet decided to leave. The decision to churn is usually made later, after a pattern of unresolved issues accumulates into a judgment about product reliability or vendor trustworthiness. But the individual tickets that feed that accumulation are filed during the period when the customer still believes the problem can be fixed. That is the intervention window. That is where the data lives.
The second thing tickets capture is specificity. A ticket contains the exact workflow the customer was trying to complete, the exact error they encountered, the exact workaround they attempted. This level of detail is operationally valuable in its own right, but it also enables a different kind of analysis. When you look at ticket content at the account level over time, the progression from specific, engaged problem-solving to short, general, resigned reporting is visible. The language is different at different stages of a customer's relationship with your product, and those differences are real and detectable.
Why we chose to build on ticket data specifically
When we were thinking about what data to use as the foundation for customer health intelligence, we looked at a few options. Product usage telemetry was one. Email communication was another. Call transcripts from tools like Gong or Chorus were a third. Support tickets were the fourth.
Usage data has the coverage and reliability problem we have written about separately: it tells you what is happening, not how the customer feels about it, and it tends to stay stable even as a customer's confidence in the product erodes. Email data has the signal, but many CS teams operate in email environments where the volume is low and the threads are short, which makes pattern detection harder.
Call transcripts are valuable for the accounts they cover, but call frequency in most B2B CS relationships is lower than support ticket frequency. The sample is thinner, and the formal structure of a scheduled call means customers are somewhat less candid than they are in a ticket filed at 9pm when the workflow just broke again.
Tickets have the best combination of signal density, temporal precision, and coverage. Most B2B SaaS companies have Zendesk, Freshdesk, or a similar platform, and those platforms contain years of customer communication in a structured format. The data is already there. The question is whether anyone has built the infrastructure to read it at the account level over time and flag the patterns that precede churn.
The classification problem we had to solve first
Reading tickets for sentiment is not a straightforward text classification problem. Felix wrote in detail about the B2B sentiment challenge in a separate post. The short version is that consumer-trained sentiment models do not work on B2B support tickets because the language register is completely different. A ticket saying "this has now failed three times this week and we cannot afford further delays to our production deployment" would score as neutral on most sentiment models. The frustration is expressed through context and implication, not through emotional vocabulary.
The classification approach that works for B2B support requires training on labeled B2B ticket data and understanding the features that carry signal in this specific context: subject line length, context richness in body text, presence or absence of expected workflow detail, shift from question-framed to statement-framed language, and changes in these features over a series of tickets from the same account.
We built our initial classification approach specifically for this context, and it continues to evolve as we process more ticket data. The model is not trying to detect whether a customer is happy or unhappy in a given ticket. It is trying to detect whether the trajectory of an account's communication is shifting in the direction that precedes a hard renewal conversation.
What this looks like in practice
When Sturdy flags an account, the output is not a health score number. It is a set of specific tickets from the last four to eight weeks, with the language patterns highlighted, and a summary of how the communication trajectory has shifted. The CSM who receives the flag sees the actual language that changed, not an abstracted score.
That specificity matters for the quality of the intervention. A CSM who knows that an account's tickets shifted from detailed bug reports to short pattern statements in the last six weeks can open a conversation about reliability directly. They can bring the relevant product context. They can escalate to the right person. A CSM who knows only that a health score moved from 72 to 64 does not have the same foundation for a targeted conversation.
The goal was never to replace CS judgment. It was to give CSMs the account-level picture that the ticket system contains but that nobody has time to reconstruct manually at renewal time. The tickets are already there. We are just reading them at scale and surfacing the patterns that matter.
