Support tickets are one of the few places where customers tell you, unprompted, what is going wrong. Most customer success teams never look at them until a renewal is already in trouble. This guide shows which ticket signals are worth tracking, how to define them so the numbers are comparable, and how to turn them into a simple score and a weekly routine.

Why support data belongs in your churn review

Usage data tells you what customers do. Support data tells you what gets in their way. A customer who logs in daily but has filed four tickets about the same broken integration is not a healthy account, even if the usage chart looks fine.

Be realistic about the evidence. Most published claims linking ticket patterns to churn come from vendor blogs, and we found no peer-reviewed study that validates specific ticket thresholds against SaaS churn. One vendor guide on reporting renewal risk with support data suggests watching ticket volume, repeat issues, reopen rate, resolution time and sentiment trend, but many of its figures are unsourced and its own thresholds are inconsistent. Treat any threshold you read, including the ones below, as a starting hypothesis. The only proof that counts is your own renewal history.

The five ticket signals worth tracking

1. Ticket volume, normalized

Raw counts mislead: a 500-seat customer will always file more tickets than a 20-seat one. Divide by active users or seats, and compare each account to its own recent baseline. The vendor guide above suggests two things worth checking: a sudden spike (it cites a threefold jump within seven days) and the opposite, a long stretch with no tickets at all, which can mean disengagement rather than satisfaction. Both are plausible, and both need your own data to confirm.

2. Repeat issues

The same problem reported again and again is more damaging than many different small questions. Tag tickets by root cause (integration, permissions, reporting, billing, bug) so repeats are visible. Three tickets about one cause is a product problem with a customer attached.

3. Reopened tickets

A reopen means the customer was told "solved" and disagreed. BoldDesk defines reopen count as the number of times a ticket moves from Solved or Closed back to any other status. Count it per account, not just per agent.

4. Escalations and priority

Track tickets raised to a higher priority, or escalated to engineering or management. An escalation is the customer, or your own team, saying the normal process is not enough.

5. Missed service targets

Targets only help if you measure against them. Freshworks gives the standard formulas:

  • First response time = time of first response minus time of ticket creation
  • Average resolution time = sum of all resolution times divided by tickets resolved
  • SLA breach rate = (breached tickets ÷ total tickets) × 100
  • SLA compliance = (tickets resolved within SLA ÷ total tickets) × 100

Note that BoldDesk calculates time metrics using SLA operational hours, not calendar time. Whatever you choose, write the definition down so support and CS read the same number.

Step 1: Agree on definitions with support

Before building anything, sit down with whoever owns support and settle these questions:

  • What counts as a ticket? Do auto-replies, internal tests and duplicates count?
  • Which clock do you use: business hours or calendar hours?
  • What does "escalated" mean in your tool, and who can set it?
  • Which root-cause tags are mandatory at close?
  • What is the observation window for each metric (for example, trailing 30 days)?

Most disagreements in a later review trace back to a skipped question here.

Step 2: Build a simple ticket-health score

You do not need a model. A weighted checklist is enough, and it is easy to explain to a customer-facing team. Here is an illustrative scheme, not a benchmark:

TICKET HEALTH (trailing 30 days) - start at 100, subtract:

Volume per active user vs. account baseline
  up 50-100%                     -10
  up more than 100%              -20
Same root cause reported 3+ times -20
Any reopened ticket               -10 (each additional: -5, max -20)
Any escalation                    -15
Missed first-response target      -5  (each, max -15)
Missed resolution target          -10 (each, max -20)

Floor at 0.
Bands: 70-100 OK | 40-69 Watch | 0-39 Act now

Tune the deductions after you run the check in Step 4. The point is a consistent, explainable rule, not a precise prediction.

Step 3: Combine tickets with other signals

Ticket data on its own produces false alarms. A customer filing many tickets because they are rolling out to a new team is a good sign. The same guide recommends alerting only when several indicators fire together, such as a usage drop plus a ticket surge. That is sensible: a ticket signal becomes much more meaningful next to a falling usage trend, a lukewarm NPS response or an overdue invoice.

This is the same logic behind a full customer health score formula: several independent signals, each with a weight, so no single noisy input decides the outcome. In XPI CRM, for example, support tickets are one of seven health score factors alongside usage trend, engagement, sentiment, NPS, billing and open work, and missed service targets, escalations and reopened tickets lower the score. XPI CRM tracks tickets rather than answering them, so your help desk stays where it is.

Step 4: Back-test against past renewals

Do this once, before you trust any threshold:

  1. List the last 20 to 40 renewals, split into renewed and churned.
  2. For each, pull ticket data for the 90 days before the renewal date.
  3. Calculate your ticket-health score for that window.
  4. Compare the two groups. Did churned accounts score lower? Which single signal separated them best?
  5. Adjust the deductions, then repeat on the next quarter's renewals.

If you have too few churned accounts to see a pattern, say so and keep the score as a prompt for conversation, not a verdict. Also audit your alerts: if only a small share lead to any action, your thresholds are too loose.

Step 5: Run a weekly ticket review

Fifteen minutes, owned by the CS lead, with a support lead invited when possible.

  • Pull accounts with renewals in the next 120 days and check their ticket-health band
  • List every account that dropped a band since last week
  • List open escalations and how long each has been open
  • Check accounts with a repeated root cause and confirm product has been told
  • Check accounts with unusually quiet support history and a falling usage trend
  • Assign an owner and a date for each account moved to Watch or Act now
  • Record the outcome so you can back-test later

Feed the accounts you flag into your wider churn risk review rather than running a separate process.

What to say to the customer

A ticket signal is a reason to reach out, not a script. A short note works well:

Hi [Name],

I noticed your team has run into [issue] a few times this month,
and I'd like to make sure it is properly fixed rather than patched.
Could we take 20 minutes this week? I'll bring an update from
our support team on root cause and timing.

[Your name]

Lead with ownership and a concrete next step. Do not quote ticket counts back at the customer.

Common mistakes

  • Using raw counts instead of normalizing by account size
  • Treating every spike as bad, when a rollout or launch explains it
  • Letting support and CS define "escalation" differently
  • Setting thresholds from a blog post and never testing them
  • Scoring tickets but never closing the loop with product on repeat causes

Try it in XPI CRM

If you want ticket signals sitting next to usage, NPS and renewals instead of in a separate tool, XPI CRM tracks support tickets with service targets per priority and feeds them into the health score and alerts for support problems. See the guides for setup, or compare it with a spreadsheet approach. Start free - every feature included, no credit card.