Key takeaway
Keep the support-system state separate from resolution evidence. In Zendesk, a solved ticket may reopen; a closed ticket instead has a new linked follow-up.
Choose the issue episode before counting resolutions
A ticket identifier is a system unit. The underlying issue may span several status changes or a later related ticket. Decide whether a proposed evaluation concerns agent actions, customer-confirmed outcomes or issue recurrence. These require different labels. A final state should not be advertised as a documented resolution unless the retained evidence supports the meaning you assign it.
Zendesk’s lifecycle documentation distinguishes reopening a solved ticket from creating a follow-up to a closed one. Its audit reference describes changes and comments. These product capabilities make an evidence map possible; they do not establish that a particular company has retained a complete history or the authority to license it.
A solved ticket reopens; a closed ticket does not
This hypothetical sequence concerns a settings problem. The agent proposes a change on ticket T600 and marks it solved. The requester replies that the issue remains, reopening the same ticket. A second action receives explicit confirmation. The ticket later closes. A subsequent report creates new follow-up F602, linked to T600. The reviewer has not yet established whether that report is recurrence or a different issue.
The timeline is illustrative and does not assert a specific automation interval. It separates submitted solution, requester evidence, system closure and a new follow-up. Treating F602 as a new independently successful case would lose the unresolved relationship question; treating it as a reopening of closed T600 would misdescribe Zendesk’s behavior.
| Event | System relationship | Evidence label |
|---|---|---|
| Action1 proposed | T600; agent comment | Solution submitted, effectiveness unconfirmed |
| Requester rejects result | T600 changes from Solved to Open | Issue continues in same ticket |
| Action2 and confirmation | T600; linked comment evidence | Requester confirms stated result |
| Automatic closure | T600 enters closed state | System lifecycle event |
| Later report | New F602 references closed T600 | Related issue; recurrence question open |
Build a map of events rather than one final summary
Zendesk audit changes include a previous and new field value. Its comment schema includes audit linkage, author information, visibility and possible attachments or metadata. Use only fields actually retained in the company’s authorized environment. A CSV containing current status and final text may lack the events needed to reconstruct the example.
An internal dictionary should record the source ticket, audit/event identifier, relevant comment, recorded status transition and your outcome label. Separate the comment author from the person or system that updated a ticket when those concepts differ. Preserve a review label when events are missing, redacted or not part of the authorized export. Do not generate plausible missing messages to make the narrative continuous.
Follow-up linkage does not bring the original conversation
Zendesk’s follow-up documentation says original comments are not copied to the new follow-up ticket. If an evaluation needs a continuous issue history, the company must establish whether the earlier conversation remains available and whether the proposed scope may include it. A link to T600 is evidence of a relationship, not evidence that F602 contains the old conversation.
For the hypothetical pair, keep T600 and F602 distinct and attach the relationship label “follow-up; recurrence not adjudicated.” Ask the support lead to review whether the later symptom concerns the same setting and whether the earlier confirmation remains relevant. A synthetic continuity illustration can explain the requested structure without exposing the customer’s text.
Public visibility is not publication permission
The comment field “public” concerns visibility in the ticket workflow; it should not be treated as a permission to publish or commercially reuse customer text. Internal notes also need their own content review. An attachment can contain another person’s account details, logs or vendor material even when its parent ticket appears ordinary.
Prepare an approved description of the evidence layers: audit history, requester/agent messages, follow-up links and exclusions. Review free text, attachments and platform metadata separately. Keep original source messages distinguishable from agent annotations or machine-written summaries. The rights review tool helps organize that agenda, while the inventory tool describes the retained category. Neither performs legal clearance or reads the support archive for you.
Ask which outcome the evaluator needs
Offer a precise description: a submitted solution, a requester-confirmed result, an internal verification or no confirmation. State the follow-up period and how missing evidence is counted. If the proposed use requires confirmed outcomes but the archive contains only final statuses, narrow the scope or stop preparation.
VOID can explore a potential route using approved metadata and permission for one named introduction. No raw ticket collection is part of that initial referral scope. Sharing a sample and granting training or other license rights are separate commitments. The completed timeline helps clarify what to ask next without representing synthetic tickets as available inventory or a successful customer case.