# Support Ticket Triage

> Agent-assist triage for an inbound customer contact: classifies it as incident, request, question or complaint, sets severity from customer impact rather than tone, routes it to the owning queue first time, and drafts a reply for a human agent to review, edit and send. It never sends, closes, refunds, promises or auto-resolves anything. Use when a ticket, chat or email arrives and needs classifying and routing, when a support queue has backed up and needs ordering, when a ticket keeps bouncing between teams, or when several contacts look like one underlying fault. Trigger on 'triage this ticket', 'what severity is this', 'which team owns this', 'draft a reply to this customer', 'the support queue is backed up', 'is this a complaint'. Not for internal staff IT issues, which are it-service-desk-triage, and not for scoring an agent's handled conversations against a quality rubric.

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

---


# Support ticket triage

## This skill does not talk to the customer

It produces a classification, a route, and a **draft**. A human support agent
reads it, edits it, and sends it — or does not. Nothing here is an auto-reply, an
auto-resolve, an auto-close, or a macro that fires on its own. If asked to send,
close, refund, credit, waive, promise a fix date, or otherwise commit the
organisation to a customer, stop and hand it to the agent. This constraint is the
skill, not a caveat on it: a plausible wrong answer sent under the brand's name
costs more than the whole triage saves.

## Purpose

Triage failures are invisible in queue metrics and expensive everywhere else. A
complaint classified as a question loses its regulatory clock. Severity set from
how angry the customer sounds starves a real outage of attention while a
well-written annoyance jumps the queue. Forty contacts about one broken thing get
worked forty times. This skill fixes the classification rules, the severity
matrix and the routing decision so the first assignment is usually right, and
gives the agent a draft that already contains what the customer asked for.

## Data classification

**Confidential.** Tickets contain personal data, account identifiers and
sometimes financial positions.

**Stop condition:** if account numbers, card details, credentials, identity
documents or financial positions are pasted into the working conversation, stop,
name the category without repeating the value, and ask for a de-identified ticket
body. Triage needs the symptom and the impact, not the customer's account.

**Never invent** a status, a cause, a fix date, an entitlement, a fee, a policy
term or a compensation figure in a draft. If the answer is not in the supplied
policy, knowledge base or ticket, the draft says what is known and marks
`[AGENT: confirm X]` at the point where a fact is needed. An unmarked guess in a
draft is worse than a gap, because the agent may not catch it before sending.

## Prerequisites

- **Inputs:** the customer's message in their own words; the product or service
  involved; when it started and whether it is ongoing; what the customer was
  trying to do and what happened instead; how many customers are affected if
  known.
- **Inputs (for routing):** the queue and ownership map; the current known-issue
  or major-incident list; the recent release or change log.
- **Inputs (for drafting):** the applicable policy or knowledge base article, and
  the tone and disclosure conventions in use.
- **Access:** the ticketing system, at read level.

If the contact does not say what the customer was trying to do and what happened
instead, the first output is the clarifying question to ask — not a guessed
classification.

## Procedure

### 1. Classify the contact type

| Type | Recognised by | Consequence of the classification |
| --- | --- | --- |
| Incident | Something that worked is broken, or the service is unavailable or degraded | Enters the incident path; may link to a major incident |
| Request | Ask for a permitted action or change — cancel, upgrade, reset, export, close | Runs the fulfilment path against entitlement checks |
| Question | Ask for information about how something works or what applies | Knowledge base path; a good answer prevents the next three |
| Complaint | Expression of dissatisfaction about the service, an outcome, or the handling — whether or not a fix is asked for | **Enters the complaints process with its own clock and record.** Never reclassify a complaint as a question to close it faster |
| Mixed | Contains more than one of the above | Split. Handle each part on its own path; do not let the easy part close the ticket |

Two rules that catch most misclassification. First, a complaint stays a complaint
even after the underlying fault is fixed. Second, "I have been charged twice" is
an incident **and** a complaint, not one or the other.

### 2. Set severity from impact and urgency, not from tone

| | Urgency: blocked now | Urgency: degraded | Urgency: can wait |
| --- | --- | --- | --- |
| **Impact: many customers** | S1 | S2 | S3 |
| **Impact: one customer, cannot transact or access funds/service** | S1 | S2 | S3 |
| **Impact: one customer, workaround exists** | S2 | S3 | S4 |
| **Impact: cosmetic or informational** | S3 | S4 | S4 |

Override upward, never downward, when: money or access to it is affected;
personal data may have been exposed; a vulnerable customer is indicated; a
regulatory or contractual deadline applies; or the contact is a repeat of one
already handled. Record any override and its reason. A polite customer locked out
of their money is S1; an angry customer with a cosmetic defect is not.

### 3. Route once, correctly

Route on the owning system or process, not on who last touched the ticket. Before
routing, check the contact against the known-issue list — if it matches, link it
rather than opening a parallel investigation, and say so in the draft. If two
teams could own it, name the primary owner and state the specific question the
second team must answer, so it does not bounce. If ownership genuinely cannot be
determined from the inputs, write `OWNER UNDETERMINED` and say what would settle
it. Do not pick a queue to make the ticket move.

### 4. Draft the reply for the agent

Structure: acknowledge the specific thing that happened, in the customer's terms ·
state what is known now · state what happens next and who does it · state when
they will hear again · one clear ask if information is needed.

Rules for the draft:

- Answer the question actually asked, first, before any explanation.
- No fix date unless one was supplied. "We will update you by [time]" is a
  commitment about contact, which is keepable, rather than about a fix.
- No cause attributed to the customer without evidence.
- No apology that admits liability where an outcome is disputed or regulated —
  acknowledge the impact, mark `[AGENT: check wording with the complaints owner]`.
- Every fact not present in the supplied inputs is marked `[AGENT: confirm ...]`.
- Match the register of the channel; a chat reply is not an email.

Hand the agent the draft plus the classification, the severity with its reasoning,
the route, and anything the draft deliberately left open.

### 5. Write the handoff summary if it escalates

Escalation summaries fail by pasting the whole thread. Supply instead: what the
customer was doing · what happened · when it started · reproduction steps or
frequency · how many are affected · what has already been tried and ruled out ·
the business impact · what is being asked of the receiving team. The last line is
the one most often missing and the reason escalations sit.

### 6. Flag the pattern

If this contact is the third of its shape today, say so. Triage that only ever
handles individual tickets keeps a broken thing alive indefinitely; the pattern
observation is what turns a queue into a fix.

## Boundaries

- **Not for** internal staff IT issues — that is `it-service-desk-triage`, which
  uses the incident/request/problem taxonomy and internal priority matrix.
- **Not for** running a live major incident's communications or the technical
  investigation — the ticket links to it, and `engineering-incident-postmortem`
  covers the review afterwards.
- **Not for** scheduling the production change that fixes the fault — that is
  `it-change-management`.
- **Not for** deciding a complaint's outcome, a refund, a goodwill payment or a
  regulatory notification. Triage records and routes; the decision is a human's.
- **Not for** answering the customer directly, under any framing.

## Hand-offs

- **Receives from:** the ticketing queue and any channel that feeds it.
- **Routes to:** the complaints function whenever the complaint classification is
  set, with the clock start recorded.
- **Routes to:** `it-service-desk-triage` when the contact turns out to be an
  internal fault reported through a customer channel.
- **Routes to:** `engineering-incident-postmortem` once an underlying incident is
  resolved and the linked ticket volume needs explaining.
- **Routes to:** `data-analytics-metric-definition` when repeat-contact or
  first-time-right measures are being argued over rather than the tickets.
- **Escalates to:** the duty manager for any S1, any suspected data exposure, and
  any indication of customer vulnerability.