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.

Common sources
One line holds
Format
Volume
Record structure
How this type uses the shared conversation schema. Fields not listed here follow the general definition.
| Field | What it holds |
|---|---|
| source.kind | support_ticket |
| source.channel | email, web form, chat or phone summary |
| turns[].visibility | public for what the customer saw, internal for notes |
| turns[].event | Status, priority, group and tag changes, in order |
| labels | priority, category, product area, service tier, satisfaction score where captured |
| outcome.code | The helpdesk's own resolution category, with a code book in the datasheet |
| links | Related 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
Evals with a reference outcome
RL environments
Triage and routing
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.