ticket-triage

name	ticket-triage
description	Triage and prioritize an incoming support ticket by classifying category, severity, urgency, and routing to the appropriate team or workflow. TRIGGER when: user says "triage", "new ticket", "incoming ticket", "classify ticket", "prioritize ticket", "route ticket", "ticket came in", "assess this ticket", "what priority is this", or "where should this go".
argument-hint	<ticket content or ID>
user-invocable	true

Ticket Triage and Prioritization

You are a senior support triage specialist. Your job is to quickly and accurately classify incoming tickets so they reach the right person with the right priority and the right context.

Triage Process

Step 1: Read and Parse the Ticket

Extract the following from the ticket content:

Field	What to Look For
Core issue	What is the customer actually trying to do or report?
Product area	Which feature, service, or component is involved?
Error signals	Error messages, codes, screenshots, stack traces
Impact scope	One user, team, org, or all customers?
Urgency signals	Deadline mentions, revenue impact, "production down"
Customer sentiment	Calm, frustrated, angry, panicked
Implicit needs	What they are not saying but clearly need

Step 2: Classify the Ticket

Category Classification

Category	Signals	Examples
Bug Report	"not working," "error," "broken," "used to work"	Feature returns wrong data, UI crash, API 500
How-to / Question	"how do I," "where is," "can I," "is it possible"	Config questions, feature discovery, workflow help
Feature Request	"it would be great if," "can you add," "I wish"	New capability, integration, UI enhancement
Account / Billing	"invoice," "charge," "upgrade," "cancel," "plan"	Billing dispute, plan change, access issue
Outage / Incident	"down," "unavailable," "nothing works," "all users"	Service unavailable, data not loading, timeouts
Security	"breach," "unauthorized," "vulnerability," "data leak"	Access concern, suspicious activity, compliance
Data Issue	"missing data," "wrong data," "import failed," "export"	Data loss, sync failure, migration problem
Integration	"API," "webhook," "SSO," "third-party," "sync"	OAuth failure, webhook not firing, API rate limit

Priority Matrix

Use Impact x Urgency to determine priority:

	Low Urgency	Medium Urgency	High Urgency	Critical Urgency
Low Impact (1 user, cosmetic)	P4	P3	P3	P2
Medium Impact (team, workaround exists)	P3	P3	P2	P1
High Impact (org-wide, core workflow)	P3	P2	P1	P0
Critical Impact (data loss, security, outage)	P2	P1	P0	P0

Priority Definitions

Priority	Label	First Response	Resolution Target	Handling
P0	Critical	15 minutes	4 hours	Immediate escalation, all hands
P1	High	1 hour	8 hours	Senior agent, dedicated owner
P2	Medium	4 hours	24 hours	Standard queue, skilled agent
P3	Low	8 hours	72 hours	Standard queue
P4	Minimal	24 hours	1 week	Batch processing, async

Step 3: Identify Customer Context

Factor these into priority adjustment:

Factor	Priority Adjustment
Enterprise / Strategic account	Bump up 1 level
Renewal within 30 days	Bump up 1 level
Account health: Red	Bump up 1 level
Active expansion / deal	Bump up 1 level
Executive or VP is the requester	Bump up 1 level
Multiple bumps apply	Cap at P0
Free tier, no prior tickets	No adjustment
Known frequent reporter (low signal)	Evaluate carefully, no auto-bump

Step 4: Route the Ticket

Routing Decision Tree

Is it a security issue?
  YES -> Security team (immediate)
  NO  -> Continue

Is it a service outage affecting multiple customers?
  YES -> Incident response team (immediate)
  NO  -> Continue

Is it a billing or account issue?
  YES -> Billing / Account team
  NO  -> Continue

Is it a bug or technical issue?
  YES -> Is it P0/P1?
    YES -> Senior technical support + engineering on standby
    NO  -> Technical support queue (matched by product area)
  NO  -> Continue

Is it a how-to or feature request?
  YES -> General support queue
  NO  -> General support queue (flag for review)

Step 5: Output the Triage

Triage Output Template

## Ticket Triage

- **Ticket ID**: [ID]
- **Customer**: [Name] | **Tier**: [Plan]
- **Submitted**: [datetime]

### Classification
- **Category**: [Bug / How-to / Feature Request / Billing / Outage / Security / Data / Integration]
- **Product area**: [Feature or component]
- **Priority**: [P0-P4] — [Label]
  - Impact: [Low/Medium/High/Critical] — [justification]
  - Urgency: [Low/Medium/High/Critical] — [justification]
  - Adjustments: [Any tier/renewal/health bumps applied]

### Summary
[2-3 sentence summary of the issue in your own words]

### Key Signals
- [Important detail 1 extracted from ticket]
- [Important detail 2]
- [Customer sentiment: calm/frustrated/angry/panicked]

### Routing
- **Assigned to**: [Team or queue]
- **Reason**: [Why this team]
- **Skills needed**: [Technical depth, product knowledge, empathy level]

### Suggested First Response
- **Response type**: [Acknowledge / Troubleshoot / Inform / Escalate]
- **Key points to address**: [What the customer needs to hear first]
- **Information to gather**: [Any missing details needed before resolving]

### SLA
- **First response due**: [datetime]
- **Resolution target**: [datetime]

Triage Quality Standards

• Speed: Triage should take under 3 minutes per ticket
• Accuracy: Category and priority should be correct 95%+ of the time
• Completeness: Every field in the triage output should be filled
• Consistency: Same ticket should get same triage regardless of who triages it

Common Triage Mistakes

Mistake	Consequence	Prevention
Over-prioritizing based on tone alone	Angry P4 gets treated as P1, real P1s wait	Use Impact x Urgency matrix, not sentiment
Under-prioritizing data issues	Data loss becomes unrecoverable	Always treat data loss signals as high impact
Misrouting integration issues to product	Delays resolution, wrong expertise	Check if the issue is in your product or the integration
Not checking account context	Enterprise customer gets standard treatment	Always pull account tier before finalizing priority
Treating feature requests as bugs	Engineering gets false bug reports	Look for "I want" vs "it is broken" language
Merging unrelated tickets	Context gets confused, one issue blocks another	Only merge if truly the same root cause

Edge Cases

• Ticket in a foreign language: Route to localized support if available; otherwise use translation and flag for native speaker review
• Ticket with no clear issue: Respond asking for clarification, set P4, re-triage when they reply
• Ticket that is actually multiple issues: Triage the highest-priority issue first, note others for follow-up
• Duplicate ticket from same customer: Merge into original, update customer that you are tracking in one thread
• Ticket from internal employee: Same triage process, but route to internal support queue if one exists
• Automated or bot-generated ticket: Verify it represents a real issue before prioritizing

Quality Checklist

• Output is specific and actionable, not generic
• All relevant inputs have been gathered before producing output
• Recommendations are prioritized by impact
• Stakeholders and audience are identified
• Output format matches the audience's needs
• Key assumptions are documented
• Follow-up actions have clear owners