Support resolution codes and CSAT: the outcome labels AI teams look for

What counts as an outcome label in a support ticket?#

An outcome label in a support ticket is any field that records how the case ended rather than what it was about. Ticket type, product area and priority describe the problem; resolution code, reopen status, escalation path and the customer's rating describe the result.

AI teams separate the two because they answer different questions. Category fields help a model route a ticket. Outcome fields tell a model, or an evaluation, which replies actually solved the problem and which ones sent the customer back a second time.

Many help desks blur the line. A single dropdown named Reason or Type often mixes symptoms such as login failure with outcomes such as user error, and that mix has to be untangled before anyone can rely on it.

• 1Resolution or disposition code: how the agent closed the case, such as configuration change, known bug, user error, feature request logged, duplicate or no response.
• 2Reopen flag: whether the customer came back on the same ticket after it was marked solved.
• 3Escalation path: whether the case moved to tier two, to engineering or to an account manager.
• 4Linked artifact: the Jira or Linear issue, knowledge base article or release note attached to the case.
• 5CSAT rating and comment: the customer's own verdict, where a survey was sent and answered.
• 6Derived timing: time to first reply and time to resolution, calculated from status timestamps.

Which outcome fields count, and how complete must each be?#

An outcome field counts when a buyer can trust what it means on every ticket where it appears and can see where it is missing. Completeness is judged period by period, so a field added halfway through your history is fine if you can say when it started.

The bar differs by field. A resolution code should be required at close for the periods you include. A CSAT rating will never sit on every ticket, and buyers expect that, but they need to know when surveys were sent and which tickets were eligible.

Reopen flags need a note of their own. If agents habitually closed a ticket and opened a fresh one when a customer came back, reopen counts understate failure, and the documentation should say so plainly.

Why resolution codes drift, and how to document the drift#

Resolution codes drift because support teams change them for sound operational reasons: a new product line needs new codes, two codes get merged, a team lead renames User error to How-to question, or a help desk migration rebuilds the list from scratch. Each change is reasonable on its own; together they make a long history of codes hard to read.

The fix is a code map, not a cleanup. Rewriting old tickets to match today's list destroys the evidence a buyer uses to judge the label, and it can introduce errors that nobody can trace later.

• 1Export every resolution value ever used, including retired and hidden ones.
• 2Record the date range in which each value was available to agents.
• 3Map retired values to current ones only where the meaning is the same, and mark the rest as unmapped.
• 4Note whether a human agent, a trigger or an automation set the value.
• 5Keep the original value beside every mapped value in the export.

How should CSAT data be read alongside other outcomes?#

CSAT data is the customer's opinion of the whole experience, which is why it works best as one outcome signal among several. A customer can rate a correct answer poorly because the answer was no, or because of a price change, and rate a slow, partial fix highly because the agent was kind.

Pairing CSAT with reopen flags and linked issues gives a fuller picture. A solved ticket with a good rating, no reopen and a linked bug that shipped in a later release tells a far clearer story than any one of those fields alone.

Survey design changes also need dates. Moving from a thumbs rating to a multi-point scale, moving the survey from the help desk to a separate survey tool, or changing which tickets trigger a survey all change what the ratings mean.

What privacy issues sit inside CSAT comments?#

CSAT comments are free text written in the moment, so they collect personal details that structured fields rarely hold. Customers name the agent who helped them, paste order or account numbers, mention colleagues, and sometimes describe health or family circumstances to explain a delay.

Agent names deserve particular care. A comment praising or criticizing a named employee is performance information about that person, so agent identities should be replaced with consistent pseudonyms across tickets, ratings and comments rather than removed in one place and left in another.

Automated detection helps but does not finish the job. The open-source Presidio project, for example, states in its documentation that automated detection cannot promise to find all sensitive information and that additional protections should be used, so plan a human review of a sample. Privacy laws such as the CCPA may apply, and how they apply is assessed deal by deal with counsel.

Illustrative: a scheduling software company audits its outcome fields#

Illustrative: a fictional workforce scheduling software company has run support in Zendesk for many years, escalates bugs to Jira, and sends CSAT surveys through the help desk. The VP of customer support is asked whether the ticket history could support a data license and starts with the outcome fields.

The audit finds that the resolution field became required only after a help desk redesign, that the code list was renamed twice, and that CSAT moved to a separate survey tool for a period before moving back. Comments from that period carry an email address but no ticket ID. Many comments name agents by first name.

The team builds a dated code map, pseudonymizes agents across every field, and excludes the survey-tool comments that cannot be tied to tickets. The resulting scope covers tickets from the required-code period with resolution codes, reopen flags, linked Jira issues and CSAT where it connects. Earlier tickets are listed separately as unlabeled history. Part of the fictional code map is shown below.

How SourceX reviews outcome labels#

SourceX reviews outcome labels during the Supply step of the SourceX five-step transaction, using metadata only: which fields exist, when each was introduced and how consistently it was filled. No tickets are shared during that first assessment.

In the SourceX Enterprise Data Value Framework, consistent labelling counts under data cleanliness and an agent's recorded decision counts as human-generated signal, so a well-labeled set of tickets can compare well with a larger unlabeled archive even though scale is also a driver. If the company proceeds, the code map, the survey history and the handling of comments are recorded in the SourceX Evidence Packet alongside provenance, licensing rights, permitted use and release authorization.