Workflow study
Triaging 650 support tickets in 30 minutes
An AI triage run across 650 Zendesk tickets that categorized and sentiment-scored every one, cross-referenced four other systems, and found that between 30 and 40 percent of the tickets did not need to be open.
- Job to be done
Find out what 650 open support tickets were collectively saying, rather than what each one said on its own.
- Inputs
- 650 Zendesk tickets
- Jira, for the engineering work behind the tickets
- Slack, for the conversation around them
- The internal knowledge base
- A vector database
- Workflow
- Categorize every one of the 650 tickets
- Score sentiment on each ticket
- Cross-reference each ticket against Jira, Slack, the knowledge base and the vector database
- Read the categories in aggregate rather than ticket by ticket
- Review point
- Needs Colin’s confirmation Not stated in the source material.
- Success criteria
- Needs Colin’s confirmation Not stated in the source material.
- Result
Completed in about 30 minutes. Between 30 and 40 percent of the tickets did not need to be open. The run also surfaced a documentation and training gap that was driving escalations and that was invisible when the tickets were read one at a time.
- Failure modes
- Needs Colin’s confirmation Not stated in the source material.
- Maintenance cost
- Needs Colin’s confirmation Not stated in the source material.
- Tools named
- Zendesk
- Jira
- Slack
- Date
, written up
- Author
Written up from Colin’s published description. The numbers are his. Six fields are flagged rather than filled, including the review point, which matters more here than in the churn study: a triage run that closes tickets without a human check is a different and riskier thing than one that proposes closures.
The finding behind the finding
“30 to 40 percent did not need to be open” is the headline, and it is the less interesting half. The documentation and training gap is the half worth copying, because it is a system-level cause that no individual ticket contained. Each ticket looked like a user who was confused. All of them together looked like a page that was missing.
Why the cross-reference is the real work
Categorizing 650 tickets is the easy part and is not where the value came from. Reading them against Jira, Slack, the knowledge base and a vector database is what turned a pile of complaints into a statement about documentation. A triage run that only reads the tickets gives you a tidier queue.
Before you repeat this
Get the review point confirmed. A support organization that acts on an unreviewed machine triage will eventually close a ticket that mattered, and the one time that happens costs more trust than the thirty minutes saved.
Open with Colin
Needs Colin’s confirmation- reviewPoint: where a human checked the output before it was acted on
- successCriteria: what counted as success before the run started
- failureModes: where this broke, mislabeled, or produced junk
- maintenanceCost: whether this now runs on a schedule
- The date the run actually happened
- Which model or service did the triage
- What was done about the 30 to 40 percent, and about the documentation gap