Software companies
CSAT and resolution outcomes: why outcome fields raise support data value
By SourceX Editorial · Updated
Short answer
Outcome fields such as final status, resolution code, CSAT rating and reopen flag raise the value of support data because they show whether an answer actually worked. With outcomes attached, an AI developer can grade a model's reply against what really resolved the case; ticket text alone shows only what agents said, not whether it helped.
Key takeaways
- An outcome field records what happened after the reply: solved, reopened, escalated, refunded or rated.
- Outcomes turn support conversations into checkable tasks, which is what evaluation and agent training need.
- CSAT on its own is a weak label; paired with reopen and resolution data it becomes much stronger.
- Most outcome problems come from exports that drop custom fields, survey data or the history of a code list.
- Unhappy and reopened cases are useful contrast examples, so label them rather than removing them.
What counts as an outcome field in a support system?#
An outcome field is any value on a support case that records what happened after the agent responded, rather than what was said. Help desks such as Zendesk, Intercom, Freshdesk and Salesforce Service Cloud keep these values near the conversation, though often in separate objects, custom fields or linked survey tools.
A COO usually knows these fields from operational dashboards. The data licensing question is different: whether each field was filled in consistently enough, for long enough, to describe the end state of individual cases.
- Final status, separating cases solved by an agent from those closed automatically for inactivity.
- Resolution code or category, the agent's label for what fixed the problem.
- CSAT rating and comment, the customer's verdict when the survey was answered.
- Reopen flag or count, showing whether the fix held.
- Escalation tier and linked engineering issue, showing when frontline support could not solve it.
- Credit, refund or replacement markers, often stored in billing or order systems.
- Timestamps for first reply, each handoff and final resolution.
Why do outcomes make support data verifiable?#
Outcomes make support data verifiable because they give each conversation a known ending that a model's answer can be compared against. A developer building a support agent can show the model the customer's first message and account context, ask what to do, and check the response against the step that actually resolved the case.
Without outcomes, the developer sees only that an agent replied. Two tickets with similar replies look identical even if one customer came back soon after, angrier than before. With a reopen flag and a resolution code, the first ticket becomes a positive example and the second a documented failure.
Evaluation benefits even more than training. Teams testing support agents need cases where the right answer is known, and outcome-labeled tickets are the closest thing to an answer key that a business archive can offer.
- 01Your work records
- 02Personal details removed
- 03You approve the release
- 04Licensed to AI developers
Which outcome signals are strong and which are weak?#
Outcome signals differ in how much they prove. A reopen recorded by the system is hard evidence that a fix did not hold, while a CSAT score reflects one customer's mood at one moment and may say nothing about the actual problem.
The strongest packages combine at least two independent signals. A case marked solved, never reopened and rated positively tells a much clearer story than any one of those fields alone.
| Field | What it shows | Common weakness | How to strengthen it |
|---|---|---|---|
| CSAT rating | Customer satisfaction when surveyed | Few customers respond; ratings mix product and agent feelings | Pair with reopen and resolution data; keep the comment |
| Resolution code | Agent's label for what fixed the issue | Codes change after reorganizations; heavy use of Other | Keep a dated history of the code list and map old codes to new |
| Final status | Whether the case ended | Auto-close rules mark silent customers as solved | Separate agent-solved cases from inactivity closures |
| Reopen flag | Whether the fix held | Rules can reopen on any reply, even a thank-you | Check trigger settings and sample reopened cases |
| Linked engineering issue | Root cause confirmed by engineers | Links missing where integrations changed | Recover links from issue keys mentioned in ticket text |
| Credit or refund | A costly outcome with a business decision | Stored in billing, not the help desk | Join on account and date, with care for privacy |
Where do outcome fields get lost in an export?#
Outcome fields usually get lost at export time, not in daily operations. Many help desks export conversation text and core fields by default, while survey responses, custom fields and audit events need separate endpoints or reports, so check your plan and the vendor's documentation before assuming a full export includes them. Gorgias, for example, says custom exports run through its support team can include ticket messages, metrics such as first response and resolution time, and CSAT scores, with its REST API as the other route to full history.
A help desk migration is the riskiest moment. Outcome fields are often left behind because the new system has no matching field, so if a switch is planned, export the old system's full field history first.
- Custom fields exported as internal IDs with no labels or value dictionary.
- CSAT responses held in a separate survey tool and never joined back to ticket IDs.
- Merged tickets whose outcome sits only on the surviving ticket.
- Resolution codes that were renamed, leaving older history full of retired values.
- Macros captured as reply text but not recorded as the macro that was applied.
- Older tickets archived beyond what the standard export reaches.
How a COO can check outcome coverage before a fit check#
A COO can check outcome coverage with reports the support team already runs, without exporting any ticket text. The aim is to know which fields are reliable, from which date, and for which queues or products.
Record unknowns rather than guessing. A field used reliably by only one team is still valuable if the package is scoped to that team's cases.
- Step 1: list every field that records an ending, including fields in survey, billing and engineering tools.
- Step 2: note when each field was introduced and any date its values were redefined.
- Step 3: count tickets with and without each field, by year and by queue.
- Step 4: read a small sample of reopened and low-rated cases to confirm the labels mean what you think.
- Step 5: write a one-page field dictionary with values, definitions and known gaps.
Illustrative: a fleet software support team maps its outcomes#
Illustrative: a fictional fleet telematics software company runs support in Zendesk, tracks bugs in Jira and sends satisfaction surveys through a separate survey tool. Its COO wants to know whether years of support history describe outcomes or only conversations.
The audit finds three problems. Resolution codes were rebuilt after a support reorganization, survey responses were never joined to tickets, and an auto-close rule marked silent customers as solved. The team maps old codes to the new list, joins survey responses by ticket ID and flags auto-closed cases separately.
The resulting package describes each case with its first message, the steps taken, the resolution code, any linked Jira issue, the reopen history and the rating. Reopened and low-rated cases stay in, clearly labeled, because they show what did not work.
How SourceX treats outcome fields#
SourceX treats outcome fields as part of the record, not as optional metadata. In the SourceX Enterprise Data Value Framework they bear most on AI utility, because outcome-labeled cases can be checked, and on data cleanliness, because consistent field definitions make those checks trustworthy. A support archive with dependable outcomes tends to rate higher on those drivers than a larger archive without them.
In the Preparation step of the SourceX five-step transaction, free-text fields such as CSAT comments get the same personal-detail removal as conversation text, because customers often write names, emails or account numbers there; that work is part of the privacy burden the framework counts against net value. The SourceX Evidence Packet then lists which outcome fields were delivered and how each was defined.
Frequently asked questions
Do low CSAT scores make a support archive less valuable?
No. Low ratings and reopened cases show responses that did not work, which helps developers teach models what to avoid and test whether a model repeats past mistakes. What reduces value is missing or unreliable outcome data, not unhappy customers. Keep negative cases and label them clearly.
What if we never used resolution codes?
Outcomes can sometimes be reconstructed from other evidence: linked engineering issues, tags, macros applied, refund records or the final agent message. Label reconstructed outcomes as derived rather than recorded, and describe the method in the field dictionary, so a developer knows how much weight to give them.
Is agent performance data a problem for our support staff?
It can be sensitive. Outcome fields tied to named agents reveal individual performance, so agent identities are usually replaced with stable pseudonyms before delivery. Employee notices and any workplace agreements should also be checked with counsel, especially where staff were told how their data would be used.
Should we change our help desk setup now to capture better outcomes?
Yes, if the changes also help operations. Separating auto-closed from solved cases, keeping a dated resolution code list and joining survey responses to ticket IDs improve reporting today and make future records more useful. Avoid changing definitions often, because every change splits your history.
Does CSAT comment text count as personal data?
Often, yes. Customers write names, contact details, order numbers and sometimes complaints about individual staff in survey comments. Treat comments like conversation text: scan them for personal details, remove what is found and review a sample by hand before any comment leaves your environment.
Sources
- Gorgias says custom exports through its support team can include ticket messages (message ID and body text), metrics such as first response time and resolution time, CSAT scores, and Help Center article content. Source
Related resources
See if your company qualifies
A short company assessment. No data uploads are needed.