Ticket Triage & Routing

skill

Classify ticket intent and severity, set priority, and route to a queue or delegate to a specialist fleet agent.

Download .md

Ticket Triage & Routing

Classify an incoming support ticket's intent and severity, assign a priority, and route it to the correct queue or delegate it to a specialist fleet agent.

When to use

  • A new ticket arrives (email, form submission, chat handoff) and needs to be sorted before a human or specialist agent works it.
  • You need to re-triage a ticket whose severity or intent has changed based on new information.
  • A backlog of untriaged tickets needs consistent priority and queue assignment.
  • A ticket requires specialized handling (billing, technical bug, account access) beyond general triage.

Tools

  • http-get
  • http-post
  • delegate-task
  • list-agents

Playbook

  1. Pull the ticket details with http-get against the helpdesk API, e.g. GET https://api.example-helpdesk.com/v1/tickets/{ticket_id}. Auth is injected by the org's Integration row for this host — never ask for, echo, or hardcode credentials.
  2. Read the subject, body, and any prior conversation history to determine intent (billing question, bug report, feature request, account access, general inquiry) using only what the org knowledge base and ticket content actually state — never invent policy or product behavior.
  3. Assess severity using observable signals: reported outage or data loss, number of affected users, customer tier, and language indicating urgency. Assign one of: critical, high, normal, low.
  4. Set the priority and queue on the ticket with http-post, e.g. POST https://api.example-helpdesk.com/v1/tickets/{ticket_id}/triage with a body containing priority, queue, and intent.
  5. If the ticket requires specialist handling (e.g. billing dispute, technical bug reproduction, security concern), call list-agents to find an available specialist fleet agent matching that domain.
  6. If a matching specialist exists, hand the ticket off with delegate-task, including the ticket ID, summary, intent, and severity so the specialist has full context without re-reading the raw ticket.
  7. If no specialist agent is available or the required action is outside your declared tools (for example, updating a customer's billing plan directly), stop and note that in the ticket via http-post as an internal comment, then flag it for human handoff rather than guessing.
  8. Any customer-facing reply you draft as part of triage is for human review before sending, unless the org has explicitly opted into auto-send — never send customer communications unilaterally.
  9. Confirm the ticket now reflects the correct queue and priority by re-checking it with http-get before considering triage complete.

Failure modes

  • Guessing at severity or intent from an incomplete ticket body instead of pulling full context first, leading to misrouted or under-prioritized tickets.
  • Inventing a policy or SLA (service level agreement) that isn't documented in the org knowledge base, rather than flagging the gap for a human.
  • Delegating to a specialist agent that doesn't exist or isn't listed by list-agents, causing the ticket to silently stall.
  • Auto-sending a customer reply when the org has not opted into auto-send, bypassing required human review.

Done when

  • The ticket has a priority and queue set that match its true intent and severity, confirmed via a follow-up http-get.
  • Tickets needing specialist handling have been delegated with full context via delegate-task, or explicitly flagged for human handoff if no specialist or tool covers the need.