How to Analyze Zendesk Tickets With AI, Step by Step
Zendesk's CSV export leaves out the ticket text. Here is how to export the comments, label every ticket with a fixed schema, check the labels and join them to outcomes.
To analyze Zendesk tickets with AI, export the tickets with their comments (the full JSON export or the API, since Zendesk's CSV export leaves the comments out), write a fixed list of categories, have a language model label every ticket against that list and nothing else, check the labels against a hand-read sample, and then join them to outcomes such as satisfaction, reopens and renewals. Each step is below, with a worked example from a sample brief we built on demonstration data.
Step 1: export the tickets with their text
Zendesk's export tools are not on by default. The account owner has to ask Zendesk Customer Support to enable data exports, and the tools are only in Suite Growth and above or Support Professional and above. Every plan can use the REST API instead. When the export finishes, Zendesk emails a link to a zip file that stays valid for at least three days.
From Zendesk's help center
Only the JSON and XML exports carry the comments, which is where the text is
Zendesk's built-in export options (Admin Center > Account > Tools > Reports) and what each includes.
| Export | Comments? | Notes Zendesk gives |
|---|---|---|
| CSV | No. Also leaves out deleted tickets and ticket descriptions | Multi-line text, multi-select and custom date fields are excluded; dates in the account time zone |
| Full JSON | Yes, unless a ticket is over 1 MB | Newline-delimited JSON; recommended above 200,000 tickets; over one million tickets comes in 31-day increments |
| Full XML | Yes | Maximum 500 MB (about 200,000 tickets); no custom ticket fields |
| Incremental Export API | From the Ticket Comments API | Available on all plans, including those without the export tools |
Two more details from that article. JSON and CSV exports skip anything updated in the six minutes before you ran them, and the date range follows each ticket's last update, not its creation date, so filter on Created at yourself once the file is open. The article also says AI agent tickets cannot be exported. For a monthly rerun, the Incremental Export API pulls only what changed since the last run.
Step 2: decide which fields you need
The comments are the input to the model. The ticket fields are what you check its labels against and what you join them to.
What to keep
The ticket fields that let you check labels and join them to outcomes
Field names as they appear in Zendesk's CSV export; the JSON export has the same data under its API names.
| Field | Why you want it |
|---|---|
| ID | Joins the comments to the ticket fields and to your labels |
| Created at, Solved at | Weekly trends, and the time window for follow-up contacts |
| Via | The channel the ticket came from; reasons differ by channel |
| Tags, Ticket type, Group | What agents and triggers already recorded; a check on the model's labels |
| Satisfaction Score | Offered, Not Offered, Good or Bad: one outcome to join to |
| Reopens, Replies, Full resolution time in minutes | Effort and failure outcomes: tickets that bounced back or dragged on |
| Organization, Requester external id | The keys that join a ticket to the account in your CRM and billing data |
Split each ticket's comments into customer messages and agent replies before labelling, and label only what the customer wrote. Agent replies are full of words like "refund" and "cancel" that describe the fix, not the problem.
Step 3: write the categories before the model sees a ticket
Read 100 to 200 tickets and write down what each customer needed. Group those notes into the questions you want answered, and make each one a field with a closed list of values. Typical fields for a support team are the contact reason, the product area, whether the issue was resolved, the effort the customer describes, and any sign of leaving. Add a definition and a "not this one when" line to every value, and include a none-of-these option so the model is never forced into a wrong box.
Leave out anything you already have as a field. If Zendesk records the channel and the CRM records the plan tier, the model should not guess them from the text.
Step 4: label every ticket against a fixed schema
Give the model the same instructions, field list and allowed values on every call, and accept only answers that match the schema (most model APIs can enforce a JSON schema). Without that, the same complaint is called "billing dispute" on Monday and "invoice issue" on Tuesday, and the counts stop meaning anything. Here is part of the schema behind our sample brief:
From a Dimension Labs config
Two of the 33 fields from the schema behind our sample Zendesk brief
Each category field is a closed list that ends in "none_detected", so the model cannot invent a category; the quote field must be copied word for word.
{
"churn_signal": {
"type": "string",
"enum": [
"explicit_churn_threat",
"vendor_evaluation_mentioned",
"competitor_named_as_alternative",
"budget_pressure_blocking_renewal",
"executive_disengagement",
"low_adoption_concern",
"contract_dispute",
"none_detected"
]
},
"sentiment_verbatim": {
"type": "string",
"description": "The exact quote from the message that most clearly captures the customer's sentiment."
}
}
Rules:
- Extract signals from the CUSTOMER's message only.
- STRICTLY extract what is explicitly stated or very strongly implied.
- All null/not-applicable values: return 'none_detected'.Three choices in that schema do most of the work. Every list ends in "none_detected", so a ticket with no churn signal says so. The quote field must be an exact substring of the customer's message, which makes it easy to check. And the rules limit the model to what the customer actually wrote.
Step 5: check the labels before you count them
Pull a sample that covers every channel and the awkward cases (one-line replies, long tickets with several problems), read each ticket, and compare your judgement with the model's. Fix the definitions where they disagree and run the sample again. When the full run is done, check a fresh sample of the production labels, because a smaller or cheaper model can slip on the harder rules.
Before the full run
Five checks we run on a labelled sample
From the QA pass on the sample brief: about 36 tickets and survey answers, three or four from each channel, edge cases included.
| Check | What fails it |
|---|---|
| Every value is on the list | A label that is not one of the allowed values |
| Text only | A label that repeats a field you already hold, such as channel or plan tier |
| Customer messages only | Labels taken from the agent's reply |
| Several signals, all captured | A ticket that names a competitor and a repeat failure but gets only one |
| Quotes are exact | A "verbatim" that is not a word-for-word substring of the ticket |
Where Zendesk already holds a related field, use it as a second check. A model label of "resolved" on tickets with several reopens, or "not resolved" on tickets rated Good, is worth reading.
Step 6: join the labels to outcomes
Counting labels tells you what customers talk about. Joining them to outcomes tells you which of those things matter. Satisfaction Score and Reopens come with the export. Renewals, downgrades, refunds and cancellations come from your CRM and billing system, joined on the organization or requester external ID.
The sample brief shows what the join can find. It read 782 customer messages from 80 accounts across eight channels, from October 2024 to March 2025, and compared each signal with each account's recorded renewal outcome in the demonstration data. Complaining was too common to separate anyone: 67 of the 80 accounts complained in support at some point. Two specific sentences did. Of the 23 accounts whose messages said they were evaluating alternatives, 91% left, against 14% of accounts that never said it.
Sample brief, demonstration data
Two sentences separated the accounts that left from the ones that stayed
Share of accounts that left, among accounts whose messages contained each sentence and among accounts whose messages never did. Across all 80 accounts, 36% left.
Wrote the sentenceNever wrote it
The same brief also asked where each warning showed up first. Support tickets carried 229 messages with risk language, against 18 to 24 in each survey channel, and for 25 of the 29 accounts that left, the earliest warning was in a support ticket. The median first warning came 205 days before the account left.
Sample brief, demonstration data
Support tickets carried most of the warning language
Messages carrying risk language, by the channel they came from.
The data in that brief is invented, so read it as a demonstration of the method, not as a benchmark. The point carries over: the useful labels are the ones you can hold against an outcome, and the outcome usually lives outside Zendesk.
FAQ
Can I analyze Zendesk tickets with ChatGPT or another chatbot?
For a few hundred tickets and a rough read, yes. It gets harder when the tickets do not fit in one prompt, when you need the same categories next month, or when you need to join the labels to renewals. That is where a fixed schema and a repeatable pipeline matter. Our post on what an AI analytics agent is covers the difference.
How many tickets should I check by hand?
Enough to cover every channel and every category you care about, with a few edge cases each. The QA pass for the sample brief used about 36, three or four per channel, then about 30 more after the production run. Our post on auditing AI agent conversations covers how sample size affects the margin of error.
Should I use Zendesk tags instead of AI labels?
Keep the tags, but as a check. They are added by many agents and triggers over many months, so the same problem ends up under different tags. A model working from one written list labels every ticket the same way.
Dimension Labs connects to Zendesk, reads every ticket and comment, adds business-specific Dimensions (custom Dimensions from the Discover plan) to each one, and joins them to your CRM, billing and usage data to show which issues are linked to renewals, cost and satisfaction. The agent then builds the reports, decks, dashboards and alerts on a schedule. See the Zendesk integration and contact center intelligence, or start with one file of tickets. Plans start at $299 a month, with no demo or sales call needed.