alihusains 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-postmortemcovers 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-triagewhen the contact turns out to be an internal fault reported through a customer channel. - Routes to:
engineering-incident-postmortemonce an underlying incident is resolved and the linked ticket volume needs explaining. - Routes to:
data-analytics-metric-definitionwhen 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.