# Ticket Triage

> 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".

- Skill: `ashutoshsrivastava17/ticket-triage` (Agent Skill)
- Install (CLI): `npx skillmds@latest add ashutoshsrivastava17/ticket-triage`
- Raw SKILL.md: https://api.skillmd.com/api/skills/ashutoshsrivastava17/ticket-triage/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Productivity
- Author: ashutoshsrivastava17 (https://skillmd.com/u/ashutoshsrivastava17)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/ashutoshsrivastava17/ticket-triage

---


# 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