Preserve the issue timeline
A ticket contains events rather than a single static description. Retain the order of messages, status changes, assignments, and relevant attachments when they are in scope. Specify whether the model acts at creation, during triage, or after closure, because the available evidence changes at each stage.
Define labels from the workflow
Priority, category, sentiment, and resolution describe different things and may come from different reviewers or systems. Record label origin and timestamp. A final category can be a useful target, but it should not appear in the model input when the task is to predict that category at intake.
Account for repeated issues
One incident can generate many tickets, copied responses, and shared knowledge-base links. Group related incidents where independent evaluation requires it and inspect duplicates explicitly. Report product, issue type, language, and time coverage so buyers can identify a dataset concentrated in a single recurring outage.
Review source and exposure
Ticket text and attachments may contain identifying details, account information, or sensitive operational context. Define exclusions and review scope before sampling. Share the prediction moment, required history, expected outputs, and privacy workflow with Fiund to discuss a suitable sourcing brief rather than assuming generic ticket exports are ready to use. Choose an incident that generated several customer reports and one shared resolution message. Inspect whether those linked records appear across evaluation boundaries and whether the target label depends on the final resolution. Document the intended treatment so incident familiarity and future context do not silently determine how easy the test becomes.
Review checklist
- Specify the model decision timestamp
- Record label origin and timing
- Group repeated incidents appropriately
- Review message and attachment exposure