Skip to content

Spec sheet / Support tickets

Support ticket dataset spec

A support ticket dataset holds helpdesk cases from first contact to closure: customer messages, agent replies, internal notes and every status change, with the outcome attached. Delivered as one JSON object per ticket in the published schema, it is the closest thing enterprise data has to labelled tasks, which makes it useful for SFT, evals and RL.

A support agent with a headset typing a reply to a ticket in a dim open office in the evening, colleagues at their screens behind him

Common sources

ZendeskFreshdeskIntercomJira

One line holds

One ticket per line

Format

JSONL in the published schema

Volume

Assembled to spec

Record structure

How this type uses the shared conversation schema. Fields not listed here follow the general definition.

Fields specific to support tickets records
FieldWhat it holds
source.kindsupport_ticket
source.channelemail, web form, chat or phone summary
turns[].visibilitypublic for what the customer saw, internal for notes
turns[].eventStatus, priority, group and tag changes, in order
labelspriority, category, product area, service tier, satisfaction score where captured
outcome.codeThe helpdesk's own resolution category, with a code book in the datasheet
linksRelated tickets, linked engineering issues, help-centre article ids

Why tickets are close to labelled tasks

Most enterprise text records what people said. A ticket also records what happened next: who picked it up, which category it was filed under, how long it waited, whether it was solved, and whether it came back. That ending is the reason tickets are worth specifying carefully. With the outcome attached, a conversation becomes a task with a result, which is what evaluation and reinforcement learning need.

The schema keeps the customer-facing exchange and the internal notes in one ordered list, separated by the visibility field. Notes are often the most instructive part: they show the reasoning an agent did not write to the customer, the escalation to a colleague and the workaround that was tried first. Status and field changes come in as events between turns, so you can reconstruct the queue history without a second file.

Outcome codes need a code book

Every helpdesk lets an organisation invent its own categories and resolution codes, and those labels drift over the years. A dataset that ships codes without explaining them is hard to use. Ask for a code book in the datasheet that maps each code to a plain description, the period it was in use, and how often it appears. If codes changed mid-period, ask for a mapping or for the period to be split.

Building tasks from tickets

For RL, the useful subset is tickets where the resolution can be checked: a refund issued, a setting changed, an article linked, a bug confirmed. Public benchmarks such as tau-bench show the pattern of an agent working against a simulated customer and a rule book. Real tickets supply the long tail of requests and the policies that a synthetic task set misses. More on that on the RL environments page.

De-identification specific to tickets

Tickets carry structured identifiers in free text: order numbers, invoice references, licence keys, addresses and bank details typed by customers who wanted a quick answer. Those must become tokens or be removed. Customer organisation names belong in the same treatment as people. Check satisfaction comments too, since customers often name the agent who helped them.

Size, sample checks and questions to ask

What drives size

  • Tickets per year and how many years the helpdesk retains
  • Average turns per ticket and the share with internal notes
  • Share of spam, auto-closed and duplicate tickets removed
  • Attachments, which are listed by type and not delivered as text
  • How many tickets link to engineering issues or code changes

Checks on a sample

  • Each ticket has at least one customer turn and one agent turn
  • The last status event agrees with outcome.status
  • Replies sent from saved macros are flagged
  • Merged tickets appear once, with the merge recorded
  • Order, invoice and account numbers are tokens, never raw
  • Satisfaction comments are de-identified like any other text

Ask the supplier

  • Which helpdesk and which export route produced the data
  • Whether internal notes are included and how they are marked
  • A code book for categories and resolution codes
  • How macro replies and automated messages are identified
  • Whether linked engineering issues or code changes can come along

Where support tickets data fits in training

SFT on resolution dialogue

How agents ask for missing information, explain a fix and close the loop, across product areas and languages.

Evals with a reference outcome

A ticket's recorded resolution gives a grader something concrete to compare a model's answer against.

RL environments

An agent plays the support role against a simulated customer, with reward from resolution codes and policy rules.

Triage and routing

Category, priority and group labels train and test classifiers on real distributions instead of synthetic ones.

FAQ

Support tickets datasets: questions

What fields should a support ticket dataset include?

The full turn history with visibility marked, status and field changes as events, labels for priority and category, and an outcome with the resolution code and whether the ticket was reopened. Links to related tickets and engineering issues add a lot.

Are internal notes useful for training?

Often more than the public replies. Notes show diagnosis, escalation and the steps tried before a fix. Ask that they are delivered and clearly marked as internal.

How do support tickets become RL tasks?

Take tickets whose resolution can be verified, turn the customer request into a task, and reward the agent when it reaches the recorded outcome within the organisation's policy rules. A simulated customer supplies follow-up turns.

How should macro replies be treated?

Flag them. Saved replies are repetitive and can dominate a model's style if left unmarked, but they are also realistic. With a flag you can sample them down.

Which helpdesks can ticket datasets come from?

Any helpdesk with an admin export or an export-capable API, including Zendesk, Freshdesk, Intercom and Jira Service Management. The export should be run by the organisation that holds the rights.

What makes one ticket dataset better than another?

Recorded outcomes, internal notes, a stable category scheme, low spam, and links to engineering work. Years of history help when products and policies changed over time.

Keep reading

Next step

Need support tickets data built to this spec?

Send the languages, period, functions and intended use. We reply by email with what can be assembled.