Churn Risk Shows Up in CS Calls Before It Shows Up in Health Scores

Most churn detection models are built from product usage data, NPS scores, and support ticket frequency. Those inputs are useful once a customer is already disengaging - they measure consequences of a problem that usually started earlier in the customer relationship. By the time usage drops or a detractor score appears, the root cause has been developing across CS conversations that were recorded but never properly analysed.

The signals that predict churn exist in CS callsbefore they show up in health scores. Escalation language, stakeholder engagement changes, absent expansion mentions, deferred action item follow-through - all surface in transcripts weeks before they register in any dashboard. The question isn't whether the signals are there. It's whether the extraction layer is there to surface them, and whether it's calibrated to mean something specific in your customer context.

Why sentiment scores miss the mechanism

Sentiment analysis applied to CS call transcripts sounds like a direct measure of customer health. In practice, it measures emotional register rather than churn risk. A customer can express everything politely while systematically pulling back: deferring to new stakeholders, skipping follow-ups, asking fewer questions about product roadmap. The sentiment score stays neutral. The churn risk is building.

The signals that actually predict churn are behavioural and structural, not emotional. Escalation language reflects urgency and unresolved issues. Stakeholder engagement changes are often more predictive still - a champion who was highly engaged starts attending calls intermittently, or introduces a new contact without explanation. Action item follow-through is a third: a customer who consistently defers what they committed to is signalling something the transcript captures directly, even when the call tone stays positive. If your health model is built primarily on sentiment, you're measuring how customers sound rather than what they're doing - and those two things diverge most sharply in the weeks before a churn decision is made.

The signals that matter - and what makes them reliable

A practical CS churn risk extraction schema covers five fields, each defined as a Brick in a churn-risk Kit: escalation language detected (yes/no with supporting quote), stakeholder engagement score (1-5, based on who attended and how actively they participated), expansion intent mentioned (yes/no - customers who are growing rarely churn), action item completion referenced (whether prior actions were followed through or deferred), and review attendance signal (was a scheduled QBR or check-in confirmed, attended, or avoided). These fields are deterministic - the same Bricks and Kits mechanism ensures consistent results, and the answers exist in the transcript.

But extracting these fields generically - with no knowledge of what escalation means at your company, what good engagement looks like for your customer tier, or what expansion signals are specific to your product - produces signals calibrated to a model's inference of what churn risk looks like in general. That's a starting point. It isn't a reliable foundation for a health model, because the definitions that matter are yours, not the model's.

What knowledge grounding changes

Knowledge grounding means attaching your own CS documents to the evaluation so it checks against your definitions rather than model inference. Your escalation policy tells the evaluation what constitutes a formal escalation in your support process versus a standard concern. Your CS methodology document defines what a healthy QBR looks like for your product and customer tier. Your product expansion documentation tells it which signals - a customer asking about additional seats, a new use case, a question about a higher tier - actually constitute genuine expansion intent for your offering.

When those documents are attached, extraction becomes specific rather than generic. The escalation Brick doesn't detect frustration language in general - it checks whether the customer expressed something that meets your company's defined threshold. The expansion intent Brick doesn't flag any mention of product growth - it checks for the specific signals your team has defined as meaningful. Account-level grounding goes further: when the evaluation has access to account context - product tier, committed outcomes from the original sale, renewal date, stakeholder structure - it can check whether what happened on a call is consistent with where that account should be. A commitment made at sale that has never been confirmed in a QBR is a different signal from a feature a customer simply hasn't needed. Without that context, both accounts look the same.

This is the distinction that matters most. Generic extraction tells you something happened. Knowledge-grounded extraction tells you whether what happened was significant for this customer, against your criteria, in your product context. See knowledge grounding for how document attachment and field-level scoping work in practice.

Building a health score from conversation data

Once those five fields are being extracted consistently - grounded in your definitions - they feed a health score that updates after each touchpoint rather than on a fixed reporting cycle. The score accumulates across the account's call history: a customer whose last three calls showed declining stakeholder engagement, no expansion mentions, and deferred action items has a very different risk profile from one where the same calls showed growing participation and expansion discussion, even if both have similar product usage metrics.

The weighting of individual signals should reflect what predicts churn in your specific customer base. For some products, escalation language is the strongest leading indicator. For others, the absence of expansion intent is more predictive - customers who aren't growing are disproportionately likely to churn at renewal. Stakeholder engagement changes tend to be broadly predictive because they reflect how much the customer's organisation values the relationship, which shows up in call attendance before it shows up anywhere else. Because the signals are grounded in your knowledge base, the score reflects your standards rather than generic model assumptions - calibration that generic extraction can't achieve.

The practical consequence is an earlier intervention window. Sentiment scores and usage data typically surface churn risk inside the window when there's limited time to act. Knowledge-grounded conversation signals typically surface it outside that window, when there's still room to change the outcome. Retrospective analysis on churned accounts usually reveals a gap of three to six weeks between when grounded conversation signals first appeared and when health scores dropped. That's the early warning time being left on the table while transcripts sit in unstructured storage.

What this changes operationally

When churn risk signals are extracted automatically and grounded in your definitions, CS managers stop making health assessments based on intuition and call notes. They review a structured signal record: which accounts showed escalation language meeting your policy threshold in the last 30 days, which had declining stakeholder engagement across three consecutive calls by your rubric, which haven't mentioned expansion in the last two QBRs as your product defines it. That's a prioritisation tool - it directs attention to accounts that need it before the situation becomes critical, while there's still time to intervene.

For SaaS CS teams managing 40 to 80 accounts per CSM, the question isn't whether signals exist in the transcripts - they always do. The question is whether there's an extraction layer that surfaces them automatically, against your standards, across every account. Manual transcript review at that volume isn't a reliable system. An extraction pipeline that runs on every call and routes grounded signals into your CS platform is.

How Semarize supports CS churn detection

Semarize is built around the combination of structured extraction and knowledge grounding that makes churn signal detection reliable rather than directional. Each signal is defined as a Brick in a Kit: escalation detected (yes/no plus supporting quote), stakeholder engagement score (1-5 with a rubric you define), expansion intent mentioned (yes/no), action item completion referenced (yes/no with context). The same Kit runs against every CS touchpoint - QBRs, check-ins, onboarding calls, executive reviews - and returns a consistent signal record across the account timeline.

Knowledge grounding is applied at the Kit level. Attach your escalation policy, CS methodology, and product expansion documentation and each Brick evaluates against those documents rather than model inference. Critically, each Brick accesses only the knowledge relevant to its specific question - so attention isn't diluted across the full knowledge base. The signals you get back are calibrated to your definitions, not to what a general model assumes churn risk looks like. Because the outputs are structured fields, they route directly into your CS platform via the API - health score inputs update after each call, without a manual review step, across every account.

Semarize extracts deterministic, knowledge-grounded churn risk signals from CS call recordings and returns them as structured fields your health scoring model can use.

Start building →

Common questions