How to Use AI to Analyze Support Tickets and Sales Calls Without Reading Everything

Pull one window, such as the last 90 days. Every item needs an ID, a link to the original, a date, the customer's account, and the full text.

Zendesk Tickets

Use the JSON export, not CSV: the CSV leaves out ticket comments and descriptions, while JSON includes comments unless a single ticket exceeds 1 MB. The admin export needs Suite Growth or Support Professional and above, plus a request from the account owner to Zendesk Support; every plan can use the REST API instead (Zendesk). If agents already tag feedback, such as product_feedback, export that tag first. For a Zendesk-only walkthrough, see how to turn Zendesk tickets into product insights.

Intercom Conversations

Intercom's dataset CSVs carry IDs, timestamps, and metrics, but "conversation/message content is not included." Inbox exports to PDF or text include the full history minus internal notes, a few hundred conversations at a time; beyond that, use the Conversations API (Intercom). To include conversations Fin resolved alone, see how to analyze Intercom conversations for product feedback.

Sales Calls in Gong and Other Recorders

For a handful of calls, open each one in Gong and choose More options, Download, Transcript (Aha! support docs). For more, a tech admin creates an API key under Admin center → Settings → Ecosystem → API (Gong Help); API access depends on your Gong plan (Dovetail Gong docs). Zoom, Google Meet, and most recorders export WebVTT or plain-text transcripts.

Keep external calls longer than about ten minutes and label each one discovery, demo, renewal, or churn. You will want to separate prospects from customers later.

Cleaning does more for accuracy than prompt wording. Cut everything that isn't the customer talking:

• Email signatures, legal footers, and quoted reply chains.
• Agent macros, auto-replies, and internal notes.
• In calls, rep monologues and demo narration. Keep the customer's turns plus the rep question just before each one.

Then redact. Regular expressions catch most emails, phone numbers, card and account numbers, and addresses; replace them with tokens such as [EMAIL]. Names in free text are harder: the open-source Presidio toolkit detects them with NLP models and pattern rules, though its docs warn that "there is no guarantee that Presidio will find all sensitive information."

On Zendesk, the Advanced Data Privacy and Protection add-on can redact sensitive data in ticket comments with triggers, and that redaction can't be reversed (Zendesk). Keep a separate lookup from each ticket or call ID to account, plan, and ARR. The model never needs names, and you join account data back in Step 5.

Most teams start with a general LLM for a one-time deep dive and move to a platform once they want the answer weekly.

What Happens to Customer Data When You Send It to an LLM?

It depends on the plan, not the provider:

• OpenAI API: not used for training by default. Abuse-monitoring logs are kept up to 30 days, and Zero Data Retention needs OpenAI's approval (OpenAI).
• ChatGPT: Business and Enterprise data is not used for training by default. Free, Plus, and Pro content can be, unless you turn off "Improve the model for everyone" in Settings → Data Controls (OpenAI Help).
• Anthropic API and Claude for Work: not used for training by default (Anthropic Privacy Center). API inputs and outputs are deleted within 30 days, with limited exceptions (Anthropic Privacy Center).
• Claude Free, Pro, and Max: each user chooses whether chats train models. Allowing it extends retention to five years; otherwise it stays at 30 days (Anthropic).

The rule: customer data goes through the API or a business plan under your company's agreement, never a personal account. Then confirm your customer contracts allow that provider as a subprocessor.

Never ask for themes straight from the raw pile. Two passes give you output you can check.

Pass 1, extraction. Send tickets in batches of about 20 to 30, or one call transcript at a time:

You are analyzing customer support tickets and sales call transcripts for a B2B software product.

For each item below, extract every distinct piece of product feedback the CUSTOMER gave. Ignore agent and sales rep statements, greetings, and account-admin requests such as password resets.

Return a JSON array with one object per feedback item:
- source_id: the item's ID, copied exactly
- quote: the customer's exact words, copied character for character, 1 to 3 sentences
- summary: the underlying problem in 12 words or fewer, in neutral language
- type: one of bug, pain_point, feature_request, usability, question, praise
- product_area: a short noun phrase such as "CSV export" or "SSO setup"
- sentiment: negative, neutral, or positive, based on the quote alone

Rules:
- Never paraphrase inside "quote". If you cannot find exact words, skip the item.
- An item can produce zero, one, or several feedback items.
- Do not guess the customer's plan, company size, or intent.

Items (ID | date | source | text):
[paste batch]

Pass 2, clustering. Once every batch is done, send only the IDs, summaries, types, and product areas:

Below are customer feedback summaries, one per line, each with an ID.

1. Propose 8 to 15 themes. Name each after a product area or problem, not a feeling or a solution. Write one sentence on what belongs in each theme and what does not.
2. Assign every ID to exactly one theme. Use "Unclear" when nothing fits; do not force a match.
3. Return a table: theme | definition | IDs.

Do not count or rank the themes. I will do that separately.

Existing themes to reuse where they fit:
[paste last period's theme list, or "none"]

Summaries (ID | summary | type | product_area):
[paste]

Then count in a spreadsheet or script: unique accounts per theme, split by source. If "Unclear" holds more than about a tenth of items, a theme is missing. For naming rules and keeping themes stable from month to month, see how to build a customer feedback taxonomy.

A raw theme count doesn't tell you what to fix first. Join each item back to its account record and add:

• Segment: plan tier, ARR band, lifecycle stage (trial, new, renewing, churned), and source.
• Sentiment: from pass 1, rolled up per theme as the share of negative items.

Judge sentiment against other themes and last month, never in absolute terms, because tickets skew negative by nature. Then look for where tickets and calls disagree; that gap is often the most useful finding. Prospects on calls describe what blocks a purchase, while customers in tickets describe what slows them down. To watch these numbers move over time, see how to tell which support ticket pain points are trending.

Run three checks before anyone sees a chart.

1. Quote check. Exact-match each quote against its source text. Anything that fails is a paraphrase; re-extract it or drop it.
2. Sample review. Mark type, theme, and sentiment right or wrong on 50 random items. If several fail the same way, tighten that theme's definition or the prompt and rerun them.
3. Miss check. Read 20 tickets the model said had no feedback. If several did, your relevance rule is too strict.

Repeat the sample review whenever you change the prompt or model.

Your real deliverable is a table, not a summary: one row per quote, with its ticket or call link, account, date, theme, type, and sentiment. When a PM says "34 accounts asked for scheduled exports," anyone should be able to open those rows and click through. The links also let you re-theme later and tell the right customers when the fix ships.