support-ticket-triager

Overview

Triages incoming support tickets through classification, routing, and response drafting. Reads ticket data from a file or pasted text, applies category and priority labels, matches routing rules to assign teams, drafts initial responses for user review, and flags tickets approaching SLA breach or requiring escalation.

Workflow

<Definition - Priority Levels> Tickets are classified into four priority tiers based on impact and urgency:

• P1 (Critical): Complete service outage or data loss affecting multiple customers. First response SLA: 15 minutes. Resolution target: 4 hours.
• P2 (High): Major feature broken with no workaround, or a single enterprise customer fully blocked. First response SLA: 1 hour. Resolution target: 8 hours.
• P3 (Medium): Feature degraded but workaround exists, or a non-blocking issue for a paying customer. First response SLA: 4 hours. Resolution target: 24 hours.
• P4 (Low): General questions, feature requests, minor cosmetic issues, or documentation gaps. First response SLA: 24 hours. Resolution target: 72 hours. </Definition - Priority Levels>

<Definition - Ticket Categories> Standard classification taxonomy for incoming tickets:

• Account Access: Login failures, password resets, permission issues, MFA problems.
• Billing: Charges, invoices, refunds, plan changes, payment method updates.
• Bug Report: Unexpected behavior, errors, crashes, data corruption.
• Feature Request: New functionality suggestions, enhancement proposals.
• Integration: Third-party connections, API issues, webhook failures.
• Performance: Slowness, timeouts, capacity limits, resource exhaustion.
• Security: Vulnerability reports, suspicious activity, compliance questions.
• Onboarding: Setup assistance, configuration guidance, initial deployment.
• Data: Export requests, migration help, backup/restore, data deletion.
• General Inquiry: How-to questions, documentation clarification, product information. </Definition - Ticket Categories>

<Definition - Escalation Triggers> Conditions that flag a ticket for immediate escalation review:

• Customer tier is Enterprise or Strategic and priority is P1 or P2.
• SLA breach is within 30 minutes for P1, or within 2 hours for P2.
• Ticket mentions legal action, regulatory compliance, or data breach.
• Customer has submitted 3+ tickets on the same issue in 7 days (repeat contact).
• Ticket language indicates extreme frustration combined with cancellation intent.
• Security vulnerability with active exploitation evidence.
• Issue affects more than 10 reported customers (widespread impact). </Definition - Escalation Triggers>

<Workflow - Triage description="End-to-end ticket triage flow: ingest, classify, route, draft responses, flag escalations, present summary." tools=[file_read, file_write, run_python, open_in_session_tab] triggers=["triage these tickets", "classify support requests", "route this ticket", "prioritize the queue", "which tickets need escalation", "auto-categorize support inbox"]

1. [Agent] Load the tickets source. If tickets_source is a file path, read it using file_read. Detect format (CSV, JSON, or plain text) and parse into a structured list. Each ticket should have at minimum: an ID (or generate a sequential one), submission timestamp, subject or title, body text, and submitter identifier. If the source is pasted text, parse each ticket boundary (look for separators, ticket IDs, or treat the entire block as a single ticket). If fails: If the source cannot be read or parsed (unreadable file, unrecognized format, or empty input), report the specific error to the user and ask them to re-provide the ticket data in a supported format.

2. [Agent] If routing_rules or sla_config files are provided, load and validate them. Confirm required fields are present and parseable. If validation fails, log the specific parsing error and notify the user that defaults will be used. Load default Priority Levels and Escalation Triggers from the Definitions section as fallback. If fails: If a provided file cannot be read at all, report the read error to the user and fall back to the default Priority Levels and Escalation Triggers rather than stopping.

3. [Think] For each ticket, perform classification:

   • Read the full ticket text. Identify the primary issue and any secondary issues.
   • Assign a Ticket Category from the defined taxonomy. If the ticket spans multiple categories, flag it for splitting per Rule 6.
   • Assign a Priority Level (P1-P4) based on described impact, scope, and urgency. Apply Rule 9: weigh actual impact over stated urgency.
   • Assess customer tone. Classify as: neutral, frustrated, angry, or ambiguous. Per Rule 7, default to neutral when unclear.
   • Calculate remaining SLA budget from the ticket creation timestamp to now.
   • Check each Escalation Trigger condition. If any trigger matches, flag the ticket and record which trigger fired.

4. [Agent] For each classified ticket, determine team routing:

   • If routing_rules are loaded, match the ticket's category and priority against the rules. Record which rule matched (per Rule 5).
   • If no routing_rules are available, apply default logic: Security tickets go to Security team, Billing to Finance Operations, Bug Reports and Performance to Engineering, Account Access to Identity team, all others to General Support.
   • If no rule matches, mark as "Unrouted" with explanation. If fails: If routing cannot be resolved for a ticket, mark it "Unrouted" with the reason and continue routing the remaining tickets.

5. [Agent] For each ticket, generate an initial response draft using the Initial Response Draft template. Tailor the draft to the ticket category and priority. For P1/P2, the tone is direct and action-oriented. For P3/P4, the tone is helpful and informational. Do not include PII in drafts. Do not promise resolution timelines beyond the SLA targets. If fails: If a draft cannot be generated for a ticket, flag that ticket as "draft pending" with the reason and continue drafting the remaining tickets.

6. [Agent] Compile the full triage summary using the Triage Summary template. Group tickets by priority (P1 first, then P2, P3, P4). Within each priority group, list escalation candidates first. Include routing assignments, SLA status, and links to drafted responses. If fails: If the summary cannot be compiled from the template, present the per-ticket classification and routing results in plain text so no triage output is lost.

7. [Ask user] Present the triage summary and all response drafts in a single structured view (per Rule 10). Highlight escalation candidates and any tickets that were split. Ask the user to review, approve, modify, or reject each routing decision and response draft. Wait for explicit confirmation before proceeding. If fails: If the user does not respond or the view cannot be displayed, save the triage report with file_write, tell the user where to find it for later review, and take no send or routing action.

8. [Agent] Apply the user's feedback. Update any routing assignments or response drafts as directed. Save the final triage report to a file using file_write and open it in the session tab for reference. If the user approved response drafts, note them as "ready to send" but do not send (per Rule 1). If fails: If the feedback cannot be applied or the report cannot be saved with file_write, report the specific error to the user and preserve the current triage state so no approved changes are lost.

</Workflow - Triage>

<Template - Triage Summary>

# Ticket Triage Summary

**Date:** {{triage_date}}
**Source:** {{tickets_source}}
**Total tickets:** {{total_count}}
**Escalation candidates:** {{escalation_count}}

## Priority Breakdown

| Priority | Count | Breaching SLA | Escalation |
|----------|-------|---------------|------------|
| P1       | {{p1_count}} | {{p1_breaching}} | {{p1_escalation}} |
| P2       | {{p2_count}} | {{p2_breaching}} | {{p2_escalation}} |
| P3       | {{p3_count}} | {{p3_breaching}} | {{p3_escalation}} |
| P4       | {{p4_count}} | {{p4_breaching}} | {{p4_escalation}} |

## Escalation Candidates

{{#each escalation_tickets}}
### Ticket {{id}}: {{subject}}
- **Priority:** {{priority}}
- **Category:** {{category}}
- **Trigger:** {{escalation_reason}}
- **SLA remaining:** {{sla_remaining}}
- **Routed to:** {{assigned_team}}
{{/each}}

## All Tickets

{{#each tickets_by_priority}}
### {{id}} | {{priority}} | {{category}}
- **Subject:** {{subject}}
- **Tone:** {{tone_assessment}}
- **Routed to:** {{assigned_team}}
- **Routing rule:** {{rule_citation}}
- **SLA status:** {{sla_status}}
- **Response draft:** See below
{{/each}}

## Response Drafts

{{#each response_drafts}}
### Draft for Ticket {{id}}
{{draft_text}}

---
{{/each}}

</Template - Triage Summary>

<Template - Initial Response Draft>

Hi {{customer_first_name}},

Thank you for reaching out. I've received your report regarding {{issue_summary}}.

{{#if priority_p1_or_p2}}
Our team is treating this as a high-priority issue and has begun investigating immediately. You can expect an update within {{next_update_window}}.
{{/if}}

{{#if priority_p3_or_p4}}
I've logged this with our {{assigned_team}} team and they will follow up within {{sla_response_target}}.
{{/if}}

{{#if workaround_available}}
In the meantime, you can try the following workaround: {{workaround_text}}
{{/if}}

If you have additional details that might help us resolve this faster, please reply to this thread.

Best regards,
{{agent_name}}

</Template - Initial Response Draft>