Reconstructing agent trajectories from ticket and case histories

This page covers the conversion method across customer support desks and IT service management (ITSM) tools. For licensing the underlying records, see customer support ticket datasets, ITSM ticket datasets and, for multi-system task histories, enterprise workflow datasets. For the wider category, start at the agent training data hub; for definitions, see ticket data and agent trajectory.

What a ticket's history records, and what it never sees

A ticket system logs every change made to the ticket record itself, with an actor and a timestamp, but it does not log the work staff did in other systems to resolve it. That boundary decides how much of a trajectory the export alone can rebuild.

In Zendesk, each update produces an audit made of events. A Change event records field_name, value and previous_value; tag changes carry arrays, SLA events carry objects, and an event carries its own via object when it arrived by a different route than its audit [1]. That via detail is how a converter tells a rule-applied change from the human update that set it off. Zendesk also states that new event types can be added at any time [1], so a parser should count and log unknown types instead of dropping them.

Other desks expose the same raw material in different shapes. Znuny presents history as a list of every action, who performed it and when [2].

ServiceNow splits the record across tables. Journal entries, the requester-visible Additional comments and internal Work notes, are stored as rows in sys_journal_field, keyed by element (comments or work_notes) and element_id (the incident's sys_id) [3]. Field changes such as state and assignment live in sys_audit, read by table name and document key; one community thread reports that the journal table had to be exposed to the REST API before it could be pulled [3]. Community answers also note that attachments and notification emails sit in separate tables (sys_attachment, sys_email), so a journal-plus-audit export omits them [3].

What no ticket history sees: the password reset in the identity provider, the refund in the billing system, the query in the monitoring console, the phone call, and the chat thread with another team. Those steps appear, if at all, as a sentence in a work note.

Mapping ticket events to observation, action and outcome steps

Each ticket event maps to one of five core step types: observation (what the agent saw), action (what the agent did), environment event (what automation or another party did), wait, and outcome signal; steps recovered from other systems are added later as a sixth, external-action type. Research on software-engineering agents analyzes trajectories as thought, action and result sequences, with task success held as a separate label [3]. Ticket histories supply the action and result layers well and the thought layer only weakly, through work notes.

Reassignments deserve their own treatment because they encode routing and escalation policy; agent-to-human handoff data covers what context should travel with them.

A table of status transitions alone (ticket ID, from-state, to-state, timestamp) is a process-mining event log, not a trajectory: it shows the path but not the messages or decisions that moved it. That shape has its own uses, covered in process mining event logs for agents. Such logs are often exchanged as IEEE 1849-2023 (XES), the XML standard for event logs and streams [3], or as OCEL 2.0, which records qualified event-to-object and object-to-object relations and attribute changes over time, in SQLite, XML or JSON [3]. The object-centric model fits ITSM data because one incident touches a requester, a configuration item, a problem record and a change request at once.

Recovering steps that happened outside the ticket

Actions taken in other systems can be recovered from linked records, integration events and work-note text, but each recovered step needs an evidence level so trainers can decide how far to trust it. A trajectory that jumps from "reassigned to network team" to "resolved" teaches a model that resolution follows reassignment, not the certificate re-enrollment that fixed the problem.

• Logged: the other system's own event, matched by ticket ID or a correlation key, such as a change request's state history, a linked bug's changelog or an identity provider's admin audit entry.
• Linked: the ticket references a record whose creation time is known but whose internal steps were not exported.
• Narrated: only a work note says it happened ("re-enrolled device cert in VPN console"). Give it a time window between the surrounding events, not a timestamp.
• Inferred: implied by a close code or field value with no supporting text.

Ask suppliers for the split of resolving steps across these four levels, not only the ticket count. Joining ticket timelines to ERP, CRM and email records is a separate problem covered in cross-system workflow records, and field-level history from business applications is covered in field-level audit trails.

Waits, pending states and time gaps belong in the sequence

Waiting is part of a ticket trajectory, not noise between actions: when an agent pauses, chases a requester or closes on silence is a policy decision a model has to learn. Typical waits are pending-requester, pending-vendor and on-hold states, scheduled follow-ups and approval queues.

Represent each wait as its own step with a reason code, the event that opened it, the event that closed it, and both calendar and business-hours durations. Keep the SLA clock state as well, since many desks pause resolution timers in pending states and a wait that looks long in calendar time may be within target.

Two failure modes recur. Auto-close after a fixed number of silent days produces "solved" tickets where nothing was solved. Bulk updates by an administrator create bursts of identical timestamps that scramble step order unless the export carries a sequence number. For cases that run for weeks, see long-horizon task records.

Outcome labels from close codes, reopens and satisfaction

The ticket record supplies four usable outcome signals (close code, reopen within a window, satisfaction score and SLA attainment), and none is ground truth on its own. Treat each as evidence with a known bias.

Define the reopen window and the follow-up matching rule in your specification, and keep auto-closed and merged tickets as separate outcome classes. The method for turning these fields into success labels is in task success labels for agent trajectories and verifying outcome labels in operational records.

The task instruction raises a related choice. When the fix differs from the reported symptom, you can keep the requester's wording (realistic for diagnosis tasks) or rewrite the goal to match what was done. Hindsight relabeling, which AgentHER applies to LLM agent trajectories, rewrites the goal to match what a trajectory achieved [3]. Keep both versions and record how the second was derived.

Worked example: a VPN incident rebuilt step by step

The record below shows the target shape: pseudonymized and typed actors, an explicit wait, an outside action marked with its evidence level, and outcome signals kept apart from the steps.

Illustrative example: invented to show structure; it does not describe an available dataset.

{
  "trajectory_id": "trj-000417",
  "source": {"system_type": "itsm", "record_type": "incident", "ticket_ref": "tkt-7f3a91",
             "tables_used": ["incident", "sys_audit", "sys_journal_field"], "converter_version": "0.4.2"},
  "task": {
    "instruction_as_reported": "Can't connect to VPN since I got my new laptop.",
    "instruction_relabeled": "Re-enroll the device certificate so the replacement laptop can reach VPN.",
    "relabel_method": "hindsight, from resolving work note n2"
  },
  "actors": {"U1": "requester", "A1": "staff: service desk", "A2": "staff: network team", "R1": "automation: assignment rule"},
  "steps": [
    {"n": 0, "ts": "2026-03-02T08:14:05Z", "actor": "U1", "type": "observation", "event": "created", "channel": "portal", "text_id": "c1"},
    {"n": 1, "ts": "2026-03-02T08:14:06Z", "actor": "R1", "type": "environment", "event": "field_change", "field": "assignment_group", "from": null, "to": "service_desk"},
    {"n": 2, "ts": "2026-03-02T08:31:40Z", "actor": "A1", "type": "action", "event": "field_change", "field": "state", "from": "new", "to": "in_progress"},
    {"n": 3, "ts": "2026-03-02T08:33:02Z", "actor": "A1", "type": "action", "event": "comment", "visibility": "public", "text_id": "c2"},
    {"n": 4, "type": "wait", "reason": "awaiting_requester", "opened_by": 3, "closed_by": 5, "calendar_s": 5410, "business_s": 5410},
    {"n": 5, "ts": "2026-03-02T10:03:12Z", "actor": "U1", "type": "observation", "event": "comment", "visibility": "public", "text_id": "c3"},
    {"n": 6, "ts": "2026-03-02T10:09:55Z", "actor": "A1", "type": "action", "event": "comment", "visibility": "internal", "text_id": "n1"},
    {"n": 7, "ts": "2026-03-02T10:10:20Z", "actor": "A1", "type": "action", "event": "field_change", "field": "assignment_group", "from": "service_desk", "to": "network"},
    {"n": 8, "ts_window": ["2026-03-02T10:10:20Z", "2026-03-02T13:41:08Z"], "actor": "A2", "type": "external_action",
     "system": "vpn_admin_console", "action": "reenroll_device_certificate", "evidence": "narrated", "text_id": "n2"},
    {"n": 9, "ts": "2026-03-02T13:41:08Z", "actor": "A2", "type": "action", "event": "comment", "visibility": "internal", "text_id": "n2"},
    {"n": 10, "ts": "2026-03-02T13:47:31Z", "actor": "A2", "type": "action", "event": "field_change", "field": "state", "from": "in_progress", "to": "resolved"}
  ],
  "outcome": {"close_code": "solved_workaround", "closed_by": "auto_close_after_resolved", "reopened_within_7d": false,
              "follow_up_ticket_within_14d": false, "csat": null, "resolution_sla_met": true},
  "gaps": ["no event log exported from vpn_admin_console", "step 8 evidenced only by note n2"]
}

Step 8 has a time window instead of a timestamp because only a work note records it. Step 1 is an environment event, so it is excluded from training targets. The gaps list tells an evaluator that the resolving action cannot be replayed from this record alone, and the two instruction fields keep the reported symptom separate from the relabeled goal.

Using converted tickets for fine-tuning and for evaluation

For supervised fine-tuning, the training targets are the staff actions, with requester messages, environment events and waits as context. For evaluation, a ticket supplies a task and an expected end state, but you still need an environment that can replay it.

On the fine-tuning side, mask the loss on non-staff steps and filter or down-weight trajectories that were reopened or reversed; rework and reopened case records explains why those are valuable as separate data. Deduplicate macro-heavy replies so the model does not learn only boilerplate. Split train and test sets by requester organization and by time, and keep merged duplicates on the same side.

For evaluation, τ-bench is a useful reference design: it pairs simulated users and programmatic APIs with domain policy documents, grades by comparing the database state at the end of a conversation with an annotated goal state, and reports pass^k, the chance of succeeding in all k trials of the same task [3]. Ticket end states (status, category, assignment, linked change) can serve as goal states the same way, but only for actions the environment can execute. Seeding that environment is covered in seed data for agent sandboxes, and grading design in agent evaluation task suites.

Pseudonymizing requesters and staff across every step

Replace every person in a ticket trajectory with one stable token across structured fields, free text and attachments in the same pass, because inconsistent replacement both breaks the trajectory and leaks identity. If a requester becomes U1 in the requester field but stays a name inside a staff reply, the model loses track of who said what and the person stays identifiable.

Identifiers in tickets hide in predictable places: names, emails and phone numbers in requester fields; staff names in signatures and @mentions; quoted email headers; hostnames, IP addresses, asset tags and employee IDs in ITSM records; order and account numbers; screenshots and log attachments. Keyed tokens (for example, an HMAC with a key the supplier keeps) give the same person the same token across tickets without shipping a lookup table.

Pseudonymized tickets are still regulated data in some regimes. Under the GDPR, data that can be attributed to a person using separately held information remains personal data (Article 4(5), Recital 26) [3], and the UK ICO takes the same position [3]. NIST SP 800-188 describes removing identifiers and transforming quasi-identifiers, and cautions that traditional de-identification has inherent limits [3]. If a supplier delivers data as "deidentified" under the California Consumer Privacy Act, the definition requires the business to contractually bind recipients to its conditions, including no reidentification [3], so expect those terms in the license.

SourceX removes or replaces personal details such as names, emails, phone numbers and account numbers before delivery, records the method used for each dataset, and checks a sample after processing; no de-identification method is perfect. The de-identified data guide covers methods in depth.

Acceptance checks before you train on converted tickets

Run these checks on a sample before accepting a converted delivery; most failures show up in the first few hundred tickets.

• Full lifecycle: share of tickets whose history runs from creation to a terminal state, with retention purges and truncated threads reported (method in case and ticket record completeness checks).
• Actor typing: every step labeled requester, staff, automation, integration or system, with the automation share reported.
• Visibility: public and internal flags kept on every comment.
• Ordering: UTC timestamps plus a sequence number for events inside one update.
• Macros: IDs kept and expansions applied consistently.
• Unknown events: unrecognized event types counted and logged [1].
• Outside actions: every recovered step carries an evidence level, with the split reported for resolving steps.
• Waits: reason, opening and closing events, and calendar and business-hours durations.
• Outcomes: a data dictionary for the close-code taxonomy and its revision dates, the reopen window and the satisfaction scale.
• Duplicates: merges and splits mapped so related tickets never straddle a train/test split.
• Pseudonyms: a sample test that the same person gets the same token across fields, text and attachments.
• Redactions: edited or deleted comments marked, so gaps are visible rather than silent.

Rights questions specific to ticket-derived trajectories

A ticket license must cover what you build from the records, not only the raw export: trajectories, relabeled instructions, environment seeds and evaluation suites. Ticket content includes requesters' own words, their attachments and third-party vendor emails, so ask how the supplier may share each.

Ask what the supplier's privacy notice and customer contracts promised about support data. In a January 2024 staff blog post, the FTC's Office of Technology warned that model-as-a-service companies that break promises not to use customer data for training may be liable under laws the FTC enforces [3]; a supplier whose own notices or contracts limited how support data may be used raises the same question. Settle whether derived evaluation sets may be shared with evaluation partners or published, what happens to derived trajectories when the license ends, and who holds the pseudonymization key. Clause-level guidance is in license terms for agent data.

When you request ticket histories through SourceX, each dataset goes through rights review, which checks that the business owns or may share the records and that required consents are in place. It is then delivered under a license that defines which records are included, what they can be used for, how long the license runs and how delivery happens.

Sourcing ticket and case histories for agent training?

Describe the ticket systems, record types, event coverage and outcome fields you need, and whether the trajectories are for fine-tuning, evaluation or both. SourceX looks for US businesses that hold those histories, checks the data and each supplier's licensing permissions, and manages the license and delivery; datasets are sourced on request, and nothing is contracted until a supplier agrees. Specify your workflow dataset with SourceX.