# Support Ticket Triage SOP — [Company name]

Template status: [Draft / In review / Approved] · Applies from: [date]

## Purpose

Get every inbound support contact to the right person at the right urgency on
the first pass, so that severity is assigned by a rule rather than by whoever
happens to read the ticket, and so that the small number of contacts that are
not support requests at all leave the support queue immediately.

## Scope

All inbound contacts arriving in [help desk] from email, in-product widget and
the community forum, from creation to first assignment and first response.

Out of scope: the work of resolving the ticket ([per-product resolution
playbooks]), incident command once an incident is declared ([Incident SOP]), and
sales enquiries.

## Owner

Accountable: [Support Lead].
Supporting: [Duty Engineer] for the escalation path, [Security Contact] for E2,
[Incident Commander] when an incident is declared.

## Trigger

A ticket is created in [help desk] with status `new`. Triage runs on every new
ticket, including ones re-opened by a customer reply after [14] days closed.

## Inputs

| Input | System of record | Required |
| --- | --- | --- |
| Ticket body, subject and attachments | [Help desk] | Yes |
| Requester email and verified account link | [Help desk] / [CRM] | Yes |
| Plan and contracted response time | [Billing system] | Yes |
| Open tickets from the same account in last [7] days | [Help desk] | Yes |
| Current service status | [Status page] / [monitoring] | Yes |

## Prerequisites

- A published severity matrix (the D2 table below) that support and engineering
  have both signed off.
- Contracted response times loaded into [help desk] per plan.
- A named [Duty Engineer] on rota for every hour the queue is covered.
- A documented security-report address that bypasses normal triage.

## Steps

1. **Check for a duplicate before anything else.** Same requester, same subject
   or same error signature within [24] hours → merge into the older ticket and
   stop. Merging late is the main cause of two agents replying differently.
2. **Confirm the requester is entitled to support.** → Decision **D1**. An
   unverified address on a paid account is not a licence to discuss account
   data; ask the verified admin to confirm.
3. **Read for the four disqualifiers** before classifying: a suspected security
   vulnerability (→ E2), a legal or data-subject request (→ E3), abusive
   content (→ E4), or a report that matches a live incident (→ E5). These leave
   triage immediately and do not get a severity.
4. **Classify the ticket type**: how-to question, suspected defect, data
   request, billing, feature request, or account change. Type drives the queue;
   severity drives the clock. They are separate fields and must not be merged.
5. **Assign severity from the matrix.** → Decision **D2**. Severity describes
   the customer's loss of function, never their tone and never their plan.
6. **Apply the response clock.** → Decision **D3**. The clock is the tighter of
   the internal target for that severity and the contracted response time.
7. **Route.** Product area from the type, then the queue rota. If more than one
   product area applies, route to the area named in the first reproduction step,
   not the first one mentioned in the subject.
8. **Send the first response.** It must state what you understood, what you are
   doing next, and when the customer will next hear from you. An acknowledgement
   with no next contact time does not count as a first response.
9. **Escalate the top severity immediately.** For S1, page the [Duty Engineer]
   and open the escalation channel before finishing the ticket notes. Do not
   wait for the response clock to run down.
10. **Record triage outcome** on the ticket: type, severity, the rule that set
    it, the queue, and any exception invoked.

## Decisions

| ID | Decision | Criteria | Default |
| --- | --- | --- | --- |
| D1 | Entitlement | Requester address verified **and** account has an active plan **or** is within [30]-day trial | Ask the verified admin to confirm |
| D2 | Severity | S1: production unusable for all users of the account, no workaround. S2: major function unusable or unusable for [n]+ users, workaround painful. S3: single function degraded, workaround exists. S4: question, cosmetic, feature request. | S3 |
| D3 | Response clock | Tighter of internal target and contracted time. S1 [30] min, S2 [4] h, S3 [1] business day, S4 [3] business days | Internal target |
| D4 | Goodwill credit | Up to [amount] at agent discretion. Above that, or any credit on a disputed invoice → approval A1 | No credit |
| D5 | Convert to incident | [2]+ unrelated accounts report the same symptom within [30] min | Keep as ticket, flag to [Duty Engineer] |

## Exceptions

- **E1 — No account can be identified.** Reply asking for the account
  identifier; do not guess from the email domain. Close after [2] unanswered
  attempts over [7] days.
- **E2 — Suspected security vulnerability.** Do not reply with details, do not
  discuss in the shared queue. Move the ticket to the restricted queue, notify
  [Security Contact] within [1] hour, and follow [Vulnerability disclosure SOP].
- **E3 — Legal notice or data-subject request.** Route to [Legal / Privacy
  Contact] the same day. Support does not answer erasure, access or subpoena
  requests from the queue.
- **E4 — Abusive or threatening content.** Stop the conversation, notify
  [Support Lead], and follow [Acceptable use policy]. Severity is not assigned.
- **E5 — Matches a live incident.** Link the ticket to the incident, send the
  incident holding reply, and do not triage independently. Reopen triage only if
  the symptom turns out to be unrelated.
- **E6 — Customer disputes the severity.** The severity stays as the matrix
  sets it. Record the disagreement and escalate to [Support Lead], who is the
  only person who may override D2.

## Approvals

| ID | What is approved | Who approves | Why it stays with a person |
| --- | --- | --- | --- |
| A1 | Goodwill credit above [amount] or on a disputed invoice | [Support Lead] with [Finance] | Money leaving the business |
| A2 | Severity override against the matrix | [Support Lead] | Keeps the matrix honest and the override visible |
| A3 | Any public statement, including a status page post | [Incident Commander] | A public statement cannot be retracted |
| A4 | Account-level configuration change requested in a ticket | Verified account admin | Change of access must come from the account, not from support |

## Output

- Every new ticket carrying type, severity, the rule that set it, queue and
  owner.
- A first response containing an understanding, a next step and a next contact
  time.
- Escalations opened for every S1 within the paging target.
- A triage log usable for weekly review of misroutes and severity overrides.

## SLA / KPI

- First response within the D3 clock: target [95%] by severity band.
- Reassignment rate after triage (misroute proxy): target under [10%].
- Duplicate merge rate: tracked, not targeted — a rising number usually means a
  broken notification, not a lazy agent.
- Severity overrides per [100] tickets: target under [3].

## Audit record

Retain for [24] months: full ticket thread, triage fields with timestamps and
the acting agent, every severity override with its A2 approval, every credit
with its A1 approval, and the routing of every E2 and E3 exception including the
handover time.

> Simulated example data
>
> Ticket [#44120] · requester verified on account [Meridian Labs] · type
> [suspected defect] · D2 → **S2** (export unusable for [12] users, manual
> workaround exists) · D3 clock [4] h, contracted time [2] h, so [2] h applied ·
> routed to [Reporting] queue · first response sent at [00:37] with next contact
> committed for [09:00].

## Revision log

| Version | Date | Author | Change |
| --- | --- | --- | --- |
| v1.0 | 2026-07-24 | [Your name] | initial draft |