AI Root Cause Analysis for Support: Finding Why Tickets Happen

By Linh Ngo · Updated Oct 11, 2026

AI root cause analysis for support is the practice of using language models to group thousands of tickets by the underlying reason customers wrote in, putting a cost on each reason, and sending the biggest ones to the product or operations team that can remove them. The goal isn't to answer tickets faster. It's to stop them from existing.

Most support dashboards report what happened: volume by channel, response time, CSAT. Very few say why. And the "why" is where the money is, because a support team can be perfectly efficient at answering a question that a one-line product fix would have eliminated. This article walks through how AI finds causes, how to price them with a formula you can run in a spreadsheet, and how to hand the findings to people who can act. It's part of the AI for Customer Service collection, and it assumes your tickets are reasonably clean (see preparing support data for AI if they aren't).

Key Facts

• BERTopic, a widely used open-source approach, builds topics in three moves: it embeds documents with a pre-trained transformer, clusters those embeddings, then describes each cluster with a class-based TF-IDF procedure (Grootendorst, 2022).
• Sentence-BERT cut the time to find the most similar pair in a collection of 10,000 sentences from about 65 hours with plain BERT to about 5 seconds, which is what made embedding-based clustering of large text sets practical (Reimers and Gurevych, 2019).
• Latent Dirichlet allocation (LDA), the classic topic model, treats each document as a mixture of topics rather than assigning it to exactly one (Blei, Ng and Jordan, JMLR, 2003). That fits tickets that mention two problems at once.
• Density-based clustering such as HDBSCAN leaves some documents unassigned. In BERTopic those outliers are labeled -1 and aren't used to build the topic descriptions (BERTopic documentation).
• k-means needs the number of clusters set beforehand and tends to produce groups of about equal size, while agglomerative clustering lets you set a similarity threshold instead (Sentence Transformers documentation).
• BERTopic's default embedding models include a multilingual option covering 50+ languages (BERTopic documentation).

Why Tags and Dashboards Miss the Cause

Most teams already "categorize" tickets. The trouble is how.

Agent-selected tags are noisy. An agent under pressure picks the closest option from a long dropdown. "Billing" ends up holding refund requests, tax questions, failed payments and plan confusion, which have four different fixes. Tags also get chosen for what's easy, not what's accurate.

Fixed taxonomies are frozen. The categories were written a year ago. A new release creates a new problem, and it lands in "Other" for six weeks before anyone notices.

Symptoms get logged, not causes. "Customer can't log in" is a symptom. The cause might be an expired invite link, an SSO misconfiguration, or a confusing password rule. Three causes, three owners, one tag.

AI changes this because it reads the actual words customers used, plus the agent's replies, and groups tickets by meaning instead of by label. A cluster called "invite link expired before the new hire opened it" is something a product manager can act on. A tag called "Account access" isn't.

How AI Finds Root Causes

Under the hood, most modern pipelines follow the same four steps. Understanding them helps you judge a vendor's claims or build a small version yourself.

Step 1: Prepare the text

Pull the customer's first message, the agent's final resolution note, and any internal summary. Strip signatures, quoted reply chains and boilerplate. If your tickets are long threads, a ticket summary often makes a better input than the raw thread, because it's short and about one thing.

Step 2: Turn each ticket into an embedding

An embedding is a list of numbers that represents a piece of text so that similar meanings sit close together. "I can't sign in" and "login keeps failing" end up near each other even though they share no words. Sentence-level embedding models made this fast enough for large ticket volumes (Reimers and Gurevych, 2019). If you support several languages, choose a multilingual embedding model so a Spanish ticket and an English ticket about the same bug land together.

Step 3: Cluster the embeddings

Clustering groups the nearby tickets. The method you pick changes what you get:

All four are described in the sources above (Sentence Transformers, BERTopic, Blei et al.). For most support teams, an embedding plus a density-based method is the practical default, because ticket data is uneven: a handful of huge themes and a long tail of small ones. A centroid-based method like k-means assumes tidier groups than you'll find.

Step 4: Name each cluster and sample it

A cluster is just a pile of tickets until it has a name. Two ways to label it: list the most distinctive words (the class-based TF-IDF step in BERTopic does this), or have a language model read 10 to 20 representative tickets and write a one-sentence description. Either way, a human should read a sample of every cluster you plan to act on. Models sometimes glue together tickets that sound alike but have different causes, like "can't export" for a permissions problem and "can't export" for a file-size limit.

Related: if you only need to sort what the customer wants (refund, cancel, upgrade) rather than why it happened, that's intent detection. Intent tells you the request type. Root cause tells you what broke upstream.

Handling Outliers and Messy Clusters

Expect imperfection. A few habits keep the output usable:

• Look at the outlier bucket every time. Unassigned tickets aren't junk. Early signs of a new problem often sit there, because there aren't enough similar tickets yet to form a cluster.
• Split big clusters. If one cluster holds 20% of your volume, it's probably several causes. Re-run clustering inside it.
• Merge near-duplicates. Two clusters with the same fix should be one line item.
• Re-run on a schedule. A monthly run on the last 90 days catches seasonal and release-driven spikes. A weekly run on the last 14 days catches regressions.

Putting a Price on Each Cause

This is the step that turns a text-mining exercise into a business case. You don't need benchmarks from anyone else's industry. You need three numbers from your own helpdesk and finance team.

The formula:

Monthly cost of a cause = tickets per month × average handle time (minutes) × loaded cost per agent-minute

• Tickets per month: the cluster size, scaled to your full volume if you clustered a sample.
• Average handle time: from your helpdesk, for tickets in that cluster, not the company-wide average. Technical causes usually take far longer than "where's my order."
• Loaded cost per agent-minute: an agent's total employment cost (salary, benefits, tools, management overhead) divided by the productive minutes they work in a month. Ask finance for it.

If you prefer to think per contact, "handle time × loaded cost per minute" is your cost per contact for that cause.

A worked example

The numbers below are made up to show the arithmetic. Replace them with your own. Assume a loaded cost of $0.75 per agent-minute.

Look at the last two columns. The cause with the fewest tickets is the most expensive, and the loudest one is only fourth. A team that fixes by volume goes after order status first. A team that prices causes goes after sync errors first. That reversal is the whole argument for doing this math.

Add the costs the formula hides

Handle time undercounts. Layer in what you can measure:

• Repeat contacts. If a cause generates follow-ups on the same issue, multiply tickets by the average number of contacts per resolved case.
• Escalations. Tickets that reach engineering consume expensive time outside support. Add that time at the engineer's loaded rate.
• Churn and refunds linked to the cause. If customers in a cluster cancel or request credits more often, that belongs on the ledger. Your churn analysis may already trace some of it.

Keep these as separate columns. A reader should be able to see the pure agent-time cost first, then the wider cost, so nobody thinks the number was inflated.

Estimate what a fix is worth

Once you have a monthly cost, the value of a fix is simple:

Monthly savings = monthly cost × share of tickets the fix eliminates

If a fix to the sync errors is expected to remove 70% of those tickets, the example above gives 0.70 × $15,750 = $11,025 a month. That's an estimate, so give your product partners a range (say 40% to 80%) and update it after the release by re-running the clusters. Compare the savings against the engineering effort. This is how you win prioritization arguments with numbers instead of anecdotes.

Routing Fixes to the Right Owner

Finding a cause doesn't fix it. Most support insights die in a slide deck because nobody owns the next step. Build the routing into the process.

A few practices make the handoff stick:

1. One page per cause. Name, plain-language description, volume trend, monthly cost, example tickets (with customer details removed), proposed owner and a suggested fix.
2. A standing review. Put a 30-minute monthly meeting on the calendar with product, operations and support. Walk the top five causes by cost, not by volume.
3. A shared ledger. Track each cause from "identified" to "fix shipped" to "ticket volume confirmed down." Closing that last loop is what builds trust. The support tickets to product backlog article covers how to write the request so it lands in an engineering queue, and routing support insights to product with AI shows how to keep the flow steady.
4. Fix the content when you can't fix the product. If engineering can't act this quarter, a better help article or a proactive notice still shaves volume.

Where This Fits With Classic Root Cause Analysis

AI clustering answers "what are the causes, and how big is each?" It doesn't answer "why does that cause exist?" That second question is where traditional methods such as the five whys and cause-and-effect diagrams come in. The root cause analysis guide covers those techniques. A workable split: AI finds and sizes the cause at the ticket level, then a small cross-functional group does the human RCA on the top two or three.

Implementing It, Step by Step

1. Pick a scope. One product line, one channel, last 90 days. Don't start company-wide.
2. Export and clean. Ticket text, resolution note, handle time, channel, product area, escalation flag. Remove personal data you don't need.
3. Run a first clustering with an embedding model and a density-based method. Expect messy output.
4. Read samples of each of the top 20 clusters. Rename, split and merge until agents say "yes, that's a real thing."
5. Price each cluster with the formula, using cluster-specific handle times.
6. Rank by cost and add the repeat-contact and escalation columns.
7. Assign owners and hand over one-page briefs for the top five.
8. Re-run monthly and track each cluster's volume against the date its fix shipped.
9. Feed the results back into planning. Separating release-driven spikes from steady-state demand makes your volume forecasts easier to trust.

Common Pitfalls

Treating clusters as truth. A cluster is a hypothesis. Read the tickets before you tell engineering about it.

Ranking by volume. As the worked example shows, the cheapest-per-ticket cause often has the most tickets. Rank by cost.

Using one handle time for everything. A company-wide average hides the long, costly tickets. Use per-cluster handle time.

Counting savings you can't confirm. Report estimated savings as a range, then measure the actual drop after the fix.

Skipping the outliers. New problems start small. If nobody looks at the unassigned bucket, you find out about them late.

One-time analysis. Causes shift with every release, so a single report goes stale fast.

Blaming agents for cause-driven volume. If one cause generates a third of the long tickets, coaching won't fix it. The product will.

Sharing raw tickets carelessly. Strip names, emails and account details before tickets leave support.