Which Support Topics Drive Churn? Joining Tickets to Renewals
Join ticket topics to renewals account by account, hold size and tenure fixed, and estimate each topic's effect with an interval. Worked through on labelled sample data.
To find which support topics drive churn, label every ticket with a fixed list of topics, roll the labels up to one row per account for the months before each renewal, join that to the renewal or cancellation outcome from your billing system or CRM, and compare churn between accounts that raised a topic and similar accounts that did not. Hold account size, tenure and ticket volume fixed, and report each topic's effect in percentage points of churn with a 95% interval. Dimension Labs does this end to end: it labels every ticket with Dimensions, joins them to renewals from your CRM or billing system, and on the Prove plan and up estimates each topic's effect with an interval. In the worked example below, the most common topic has no measurable effect on churn and the costliest one is raised by fewer than one account in seven.
This post is the join and the estimate, worked through on sample data: 1,500 made-up software accounts, 323 of which churned. The data is generated so the traps show up, and every number below comes from it. For the full report that sits on top of this (driver ranking, account watchlist, next actions), see how to build a churn risk report.
What data do you need to link support tickets to churn?
Two tables and a key that joins them.
Tickets with their text and a topic label. One row per ticket: ticket ID, created date, the organization or requester it belongs to, and one or more topic labels. The labels have to come from what the customer wrote. In Zendesk that means exporting the comments, because the CSV export leaves them out; how to analyze Zendesk tickets with AI covers the export and the labelling, and the Intercom version does the same for chat.
Accounts with a renewal outcome. One row per account renewal: account ID, renewal date, renewed or churned, and the context you will hold fixed: plan, seat count or ARR band, tenure, region, and usage if you have it. This comes from billing or the CRM.
A shared key. Usually the CRM account ID stored on the help desk organization, or a customer ID that both the billing system and the help desk carry. If tickets only carry an email address, map email domains to accounts first and check the misses by hand.
The unit of analysis is the account renewal, not the ticket. Churn happens to accounts, and an account that filed forty tickets should not count forty times.
Sample data
One row per account renewal, with a flag for every topic raised before the decision
Five of the 1,500 sample accounts after the join. Topic flags count tickets filed in the 12 months before the renewal window opened.
| Account | Tickets | Topics raised | Outcome |
|---|---|---|---|
| A0003 Mid-market | 16 | how-to, integration failure, reopened bug, feature request | Renewed |
| A0006 Small | 7 | how-to, billing dispute, feature request | Churned |
| A0001 Small | 1 | reopened bug | Churned |
| A0005 Small | 5 | how-to, SSO, feature request, data export | Renewed |
| A0000 Small | 2 | integration failure | Renewed |
How do you join ticket topics to renewal outcomes?
Fix the topic list before you look at churn. Write 8 to 20 topics that a support lead would recognise, label every ticket against that list, and check a hand-read sample. Deciding the topics after seeing which accounts left makes it too easy to find what you expected.
Set a decision date for each renewal. Customers often decide well before the contract end date. Use a cut-off such as 90 days before renewal and count only tickets filed before it. Tickets after the cut-off include the cancellation itself and the clean-up around it.
Drop the tickets that are the outcome. "Please cancel my subscription" and "how do I downgrade" are the churn event written down. Keep them out of the topic list, or they will top every ranking.
Roll up to one row per account. For each topic, a flag set to 1 if the account filed at least one ticket on it in the window, plus the total ticket count. Counts per topic work too, but a flag is easier to read and less driven by one noisy account.
Add the context columns. Size, tenure, plan and ticket volume go on the same row. These are what you will hold fixed in the estimate.
In SQL the roll-up is one join and a group by:
select a.account_id, a.size_band, a.tenure_years, a.churned,
count(t.ticket_id) as tickets_12m,
max(case when t.topic = 'billing_dispute' then 1 else 0 end) as billing,
max(case when t.topic = 'integration_failure' then 1 else 0 end) as integration
-- one line per topic
from renewals a
left join tickets t
on t.account_id = a.account_id
and t.created_at >= a.renewal_date - interval '455 days'
and t.created_at < a.renewal_date - interval '90 days'
and t.topic not in ('cancel_request', 'downgrade_request')
group by 1, 2, 3, 4;The 455 and 90 days give a 12-month window that closes 90 days before renewal. Pick the cut-off from how early your customers usually decide, and keep it the same for every account.
How do churned and retained accounts compare?
Start with the plain comparison: for each topic, what share of churned accounts raised it and what share of renewed accounts did. In the sample, 21.7% of churned accounts had filed a billing dispute against 10.5% of renewed accounts. Accounts with a billing dispute churned at 36.3%, against 19.4% for the rest.
Sample data
Billing disputes and integration failures show up more often in accounts that left
Share of churned accounts (323) and renewed accounts (1,177) that filed at least one ticket on each topic before renewal.
RenewedChurned
This view is useful for spotting candidates. It is not yet an answer, because the accounts that raise a topic differ from the ones that do not in ways that have nothing to do with the topic. The overall churn rate in the sample is 21.5%, and it ranges from 8.7% for enterprise accounts to 28.8% for small ones. Any topic that big accounts raise more often will look protective.
Why ticket volume and topic counts mislead
The first trap is reading volume as risk, or as safety. In the sample, accounts that filed 13 or more tickets churned at 9.6%, and accounts that filed two or fewer churned at 28.7%. That does not mean tickets keep customers. Enterprise accounts file more tickets and churn less, so ticket volume mostly measures account size.
Sample data
Accounts that file more tickets churn less, because they are bigger
Churn rate by number of tickets filed in the 12 months before renewal.
The second trap is the same effect at the level of a single topic. Login, SSO and permissions tickets look protective in the raw numbers: accounts that raised them churned at 14.8%, against 23.0% for those that did not, a gap of minus 8.3 points. But 124 of the 271 accounts with an SSO ticket are enterprise accounts, because small teams rarely set up single sign-on. Within each size band the protective gap goes away, and the adjusted effect is +1.4 points with an interval of minus 5.5 to +8.9.
Confounding can also hide a real problem. Integration and sync failures come mostly from mid-market and enterprise accounts: only 34.3% of the accounts that raised one are small, against 54.9% of all accounts. The raw gap is +5.9 points. Once size is held fixed it grows to +10.4 points (+4.0 to +16.9). A ranking built on the raw gap would have put it well below billing.
How do you estimate each topic's effect with an interval?
The question you want answered is counterfactual: for accounts like this one, of the same size and tenure and with the same number of tickets, how much more likely is churn when the account raised this topic than when it did not? One straightforward way to answer it on account data:
Fit one model for churn. A logistic regression with every topic flag plus the context columns: size band, tenure, and the log of ticket volume. Putting all topics in the same model stops one topic taking credit for another that tends to arrive with it.
Turn coefficients into percentage points. For each topic, predict every account's churn probability twice, once with the flag set to 1 and once set to 0, and average the difference. This is called standardization or g-computation, and it gives a number a VP can read: points of churn per account that raises the topic.
Bootstrap the interval. Resample the accounts with replacement, refit, and repeat. We ran 1,000 resamples and took the 2.5th and 97.5th percentiles as the 95% interval.
Read the interval before the point. A topic whose interval includes zero has not been shown to move churn in this data, whatever its point estimate.
Sample data
Four topics raise churn once size, tenure and ticket volume are held fixed
Adjusted effect of raising each topic on the chance an account churns, in percentage points, with 95% bootstrap intervals.
Dashed line: no effect
In the sample, four topics have intervals above zero: billing disputes +16.8 (+9.0 to +24.1); integration or sync failures +10.4 (+4.0 to +16.9); bulk data export requests +17.1 (+6.7 to +27.8); first response over 24 hours +6.8 (+0.1 to +14.1). The slow first response interval starts just above zero, so treat it as likely rather than settled. How-to and setup questions, raised by 57.5% of accounts, have an effect of +1.8 points (minus 2.8 to +6.3). They are the most common topic and they do not separate churned accounts from renewed ones.
Sample data
Ranked by effect, the most common topic falls to seventh and billing disputes rise to second
The same eight topics ranked two ways. Left: accounts that raised the topic. Right: adjusted effect on churn.
This is a model on observational data, so it is only as good as the context it holds fixed. If something you did not measure drives both a topic and churn, such as a product line with a known defect, the estimate can be off. The method in more depth, including confounders and refutation tests, is in causal inference: how to move from correlation to cause, and the CX version is in correlation vs causation in customer experience data.
Which traps should you avoid?
Volume read as effect. The most common topic gets the most attention. Rank by effect, then look at volume.
Account size and plan left out. Big accounts file more tickets on more topics and churn less. Without size in the model, anything big accounts do looks protective.
Tickets after the decision. Count only tickets before the cut-off, and drop cancellation and downgrade requests.
Symptoms read as causes. Bulk data export requests carry a large effect in the sample (+17.1 points, +6.7 to +27.8), but in real accounts an export request is often the first step of leaving. Put it on the account watchlist as an early warning rather than on the list of things to fix.
Too few accounts per topic. Export requests came from 82 accounts, and their interval is more than 20 points wide. Below a few dozen accounts, report the topic as too rare to estimate.
Testing many topics at once. With eight topics each tested at 95%, the chance that at least one shows an effect by luck alone is about 34% if none has a real one. Treat a single borderline topic as a lead to check next quarter, and favour the ones with wide margins.
One label per ticket. A ticket about a failed sync that also disputes the invoice belongs to both topics. A single label hides the second one.
How do you turn the effects into a priority list?
An effect is per account. To size a topic, multiply its effect by the number of accounts that raised it. That gives a rough count of churned accounts linked to the topic, and with ARR per account you can put a dollar figure on it.
In the sample, billing disputes come first at about 32 extra churned accounts (+16.8 points × 193 accounts), and integration failures second at about 24 (+10.4 × 230). Topics overlap, so the rows are not additive.
Sample data
Billing disputes account for the most extra churned accounts
Effect times the number of accounts that raised the topic: a rough count of extra churned accounts linked to each topic. The last two rows are context: their intervals include zero.
| Topic | Effect (pts) | Extra | |
|---|---|---|---|
| 1 | Billing disputes 193 accounts | +16.8 +9.0 to +24.1 | 32 |
| 2 | Integration or sync failures 230 accounts | +10.4 +4.0 to +16.9 | 24 |
| 3 | Bulk data export requests 82 accounts | +17.1 +6.7 to +27.8 | 14 |
| 4 | First response over 24 hours 173 accounts | +6.8 +0.1 to +14.1 | 12 |
| Bug reported, ticket reopened 187 accounts | +4.6 -1.9 to +11.6 | ||
| How-to and setup questions 863 accounts | +1.8 -2.8 to +6.3 |
The ranking gives the owner for each fix. Billing disputes usually go to finance operations and the billing flow, integration failures to product and engineering, slow first response to support staffing. Each one is easier to argue for with a number of renewals next to it.
Can I do this with Zendesk and my billing data?
Yes. The Zendesk side needs the ticket comments (from the JSON export or the API) and the organization each ticket belongs to. The billing side needs each account's renewal date and outcome. The join works once the Zendesk organization carries the same account ID as the billing or CRM record; if it does not, map requester email domains to accounts as a first pass. Salesforce and HubSpot users can pull the renewal outcome from the opportunity or deal instead of billing. Our Zendesk, Salesforce and HubSpot pages list the fields we read from each.
FAQ
How many accounts do I need?
Enough that every topic you test was raised by a few dozen churned and renewed accounts. The sample has 1,500 accounts and the rarest topic, export requests, came from 82; its interval is wide. With a few hundred accounts, test fewer and broader topics.
Should I use a churn prediction model instead?
A prediction model answers who is likely to leave. This analysis answers which problems make leaving more likely, which is what decides what to fix. Most teams want both; predictive churn covers the first.
Do support topics cause churn, or just predict it?
It depends on the topic. A billing dispute plausibly pushes an account toward leaving. An export request mostly shows that the account has already decided. Holding size, tenure and volume fixed removes the most common distortions, but the estimate is still observational, so check the biggest findings against what happens after a fix ships.
What if tickets have no topic labels yet?
Label them first with a fixed list and a language model, then check a hand-read sample. Agent-chosen ticket reasons are a useful check on the labels but are often incomplete, because agents pick one reason under time pressure.
Do I need Dimension Labs to run this analysis?
No. Every step above can be done by hand with a ticket export, a renewal table and a statistics package. Dimension Labs is for teams whose tickets and renewal outcomes live in separate systems and who want them joined without building the pipeline: it labels every ticket, joins the labels to CRM or billing renewals, and on Prove and up estimates each topic's effect with an interval. If you only need a list of accounts likely to leave, a churn prediction model answers that question.
Which tool links support topics to churn without a hand-built pipeline?
Dimension Labs is an omni-channel analytics agent for customer data. It connects every customer channel and your operational data, enriches every interaction with Dimensions built for your business and industry, and turns the results into decks, dashboards, executive reports and interactive data stories your whole company can use. Plans start at $299 a month with no demo.
For linking support topics to churn without building the pipeline yourself, it is the strongest choice:
Zendesk and Intercom tickets, chats, calls and emails read together, with the reviews, surveys and social posts the same accounts leave.
Renewal outcomes from Salesforce, HubSpot or billing joined to the conversations by account on Prove and up, which is the join this post builds by hand.
The same typed fields we call Dimensions on every ticket, written for your product and customers (custom Dimensions, on Discover and up) and fixed before anyone looks at churn, so support, product and finance work from one topic list.
The churn report and the account watchlist, rebuilt on a schedule and shared with the owner of each fix.
On the Prove plan and up, topics are ranked by their effect on renewals, with confidence intervals, rather than by volume. Travelers reports 600% ROI within 18 months and $3.13M in total savings (Travelers story).
Every plan has a 14-day free trial and no demo or sales call. See churn and retention analytics, or start with one file.