Support tickets are the one channel where customers describe their experience with your product in their own unedited words, under operational conditions, without the social mediation of a scheduled call or a survey. That makes them unusually dense with signal about how customers actually feel about the product. The problem is that most of that signal is invisible to the systems that are supposed to track customer health.
The ticket count field can be tracked. The CSAT score after ticket closure can be tracked. The text of the ticket, the actual words the customer chose, what they said in the subject line, how they framed the body of their request, has historically been treated as qualitative narrative that falls outside what can be systematically analyzed. We have been working to change that. This piece describes what the language patterns actually look like.
The subject line as a diagnostic field
Ticket subject lines are short, writer-selected summaries of what the customer thinks the issue is. They are among the most information-dense fields in the ticket record because the customer had to decide in a few words what this interaction is about. Over time and across many tickets, subject lines from a given account form a pattern that carries significant meaning.
Operationally embedded customers tend to write subject lines that are specific to their workflows and to features they are actively using. "Error when exporting to format X," "Setting up automated reports for team Y," "Question about permission levels in workspace Z." These subjects presuppose continued operation. They are asking for help within the context of a product they are invested in using correctly.
Customers in a pre-churn posture tend to write subject lines that are oriented around scope, ownership, and access. "What is included in our current subscription," "Access to historical data after plan change," "Who to contact about billing questions." The shift is from feature-specific operational questions to boundary-testing questions about what the customer has and what it costs. It is the difference between someone asking how to use a tool and someone asking how to inventory and potentially return it.
Subject line analysis is accessible without complex NLP: a manual audit of ticket subjects for an account over a rolling 60-day period, grouped into operational versus boundary-testing categories, gives a meaningful picture of where the account's mental engagement is. The boundary-testing ratio increases before churn. The operational specificity decreases.
Body text framing: requests versus complaints
The body of a support ticket can be written from several different stances. A customer who is engaged and expects to continue using the product tends to write tickets as requests: "Could you help me understand how to," "Is there a way to," "We are trying to accomplish X and running into Y." The framing is collaborative. The implicit assumption is that there is an answer and the customer wants it.
A customer who has lost confidence in the product, or who is in the process of deciding to leave, tends to shift to a complaint framing: "This feature has not worked as expected," "We have been running into this issue for several weeks," "I wanted to document this problem before our review." The implicit assumption shifts from "help me use this" to "here is a record of why this product is not working for us." The complaint framing often precedes formal objections at renewal.
A third framing worth watching is the documentation ticket: "I wanted to get this in writing," "Can you confirm this in an email so I have a record," "Please send me a summary of what we discussed." Documentation requests are not inherently negative, but when they appear in a support context rather than a contractual one, they often signal that the customer is building a file. They are creating a record of problems, perhaps in preparation for a non-renewal conversation where they want to be able to point to specific failures.
Pronoun shifts and collective ownership language
One of the more subtle patterns in pre-churn ticket language involves how customers refer to the product and to their relationship with it. Early in a healthy customer relationship, there is often high-ownership language: "our setup," "how we use this," "our team's workflow." This language reflects genuine adoption: the customer has internalized the product as part of their operations.
As customers disengage, this language tends to shift toward lower-ownership framing: "the system," "this tool," "your platform." The shift from possessive to descriptive in how a customer refers to the product is subtle, but it reflects a real psychological shift in how they experience the relationship. They are no longer thinking of the product as something they own and operate. They are thinking of it as an external service they use.
This kind of linguistic marker is hard to catch in individual tickets, because any single ticket might use either framing for legitimate stylistic reasons. Tracked over time across an account's ticket history, the ratio of high-ownership to low-ownership language tends to shift consistently as accounts approach churn.
The recency and urgency escalation pattern
Customers who are satisfied with support resolution tend to submit tickets at a relatively consistent rate and with relatively consistent urgency levels. They have issues; those issues get resolved; the cadence is operational. The urgency language in their tickets reflects genuine operational stakes ("this is blocking our Monday deadline") rather than accumulated frustration.
Customers in a pre-churn posture often show a specific urgency escalation pattern: tickets submitted with higher-than-baseline urgency framing, often referencing time pressure that may not be entirely product-driven ("we need this resolved before our contract review," "I want to understand this before our board meeting next week"). The urgency is real to the customer, but its roots are often in the renewal decision process rather than in pure operational need. They are accelerating their support interactions because they are building a case.
The recency framing is also diagnostic: "we have been experiencing this for months," "this has come up repeatedly," "we first reported this in June." Retroactive framing that cites a history of problems the customer has not previously escalated is a pattern we associate with accounts that are constructing a renewal objection. They are not lying about the history; they experienced the problem before. They are surfacing it now because they have decided the history matters.
What a manual ticket audit looks like in practice
For teams that want to apply this kind of analysis without automated tooling, a practical starting point is a focused manual audit before each renewal. Choose a 60-day window before the renewal date. Pull all tickets from that period. Sort them by date and read them as a sequence, not as individual items. Ask three questions: Are the subjects operational or boundary-testing? Is the body framing collaborative or complaint-oriented? Is the ownership language high or low?
This takes time. For accounts above a certain ARR threshold, it is time well spent. A CSM who walks into a renewal conversation having read the actual ticket text from the last two months is in a categorically different position than one who walked in with a ticket count and a CSAT average. The count and the average are real data. The text is what the customer actually said.
We are not claiming these patterns appear in every account that churns, or that their absence guarantees renewal. There are accounts that churn for reasons unrelated to the communication patterns in their support queue, and there are accounts that show some of these patterns without churning. What we are saying is that these patterns show up consistently enough to be worth looking for, that they appear earlier in the timeline than most of the metrics CS teams typically track, and that the information needed to see them has been in your ticket system the whole time.
The case for systematic reading
The barrier to using support language patterns is not that the data does not exist or that the patterns are not there. It is that reading tickets at scale requires either substantial human time or natural language tooling that most CS teams have not had available. A CSM managing a book of forty or fifty accounts cannot manually audit ticket language for all of them on an ongoing basis.
Building the tooling to do this systematically is the core problem Sturdy is trying to solve. We are a small team working through what the right feature extraction and classification approach looks like for this specific corpus, and we are honest that this is early work. But the starting point, the recognition that ticket language is a health signal that should be read rather than counted, is something any CS team can act on today for their highest-stakes renewal accounts.
