A ticket table can show what is open or closed now. A support-resolution collection can show the request, the response, a failed attempt or escalation and the recorded outcome. Compare those two scopes for the same requests and time period. The difference is the retained sequence and its connections, rather than a larger file count.
Two fictional collections for one request
Snapshot A contains request T-118, opened on April 3, currently marked closed. Collection B contains the same request plus replies, an escalation on April 4, a reopening on April 6 and a closing note on April 7. Both descriptions can be accurate. Only the second supports tracing those intermediate events.
Use fictional IDs to understand the structure, then inspect the real fields available in your own records. Do not assign a reopening merely because two messages mention the same problem.
| Stage | Fictional record | Relationship to inspect |
|---|---|---|
| Request | Ticket T-118 | Persistent ticket ID |
| First response | Reply R-11 | T-118 and reply time |
| Escalation | Event E-9 | T-118 and receiving team |
| Reopening | Event E-12 | T-118 and status change |
| Resolution | Note N-6 | T-118, result and closing time |
Separate an outcome from a status
Closed is a state. Replaced the failed part and confirmed the service resumed is an explanation of a result. Inventory them separately. A closing flag may exist for every request while resolution notes exist only for some teams or later periods.
A reopening is particularly useful for checking the sequence. Does the second attempt preserve the original request reference, create a child ticket or create a new unrelated record? Write the observed behavior in the relationship field rather than forcing all attempts into one row.
Inspect the period shared by the groups
Suppose ticket rows begin in 2022, replies in 2024 and escalation events in 2025. The three groups can describe a shared period only from the latest relevant start date, assuming their end dates overlap. Older ticket rows remain a separate collection. A shared period still requires links between individual records.
Turn gaps into support-specific questions
Look at one routine resolution and one reopened case. Compare whether attachments, internal notes and the result survive in both. If only the customer-facing replies are exported, say so. If an attachment is a URL, check whether the underlying file remains available before describing it as an included file.
- Can ticket and conversation identifiers be matched?
- Are reassignment and reopening explicit events?
- Is the recorded outcome more detailed than closed?
- Which record group has the shortest observed history?
- Are thread replies and file references present?
Relate the inventory to buyer evidence
Appen’s decision-and-resolution category is a relevant broader route; micro1’s support-workflow examples provide another scope question. Consult the evidence matrix for the exact statement. Describe your actual request, event and outcome groups when asking whether they fit.
Questions about this comparison
Can we start with a ticket CSV alone?
Yes. Inventory it as a ticket snapshot, then identify the replies, events and outcomes still to inspect.
Does a closed date establish resolution quality?
No. It establishes the recorded date field. The nature and quality of the outcome need their own evidence.
What if one issue creates several tickets?
Keep each ticket ID and record the explicit parent, duplicate or related-ticket reference, where present.
Sources
- Appen program pageAppen · Checked 2026-10-06
- Monetize your company's operational data (micro1)micro1 · Checked 2026-10-12