An agent that triages support tickets

Last reviewed 27 July 2026

A triage agent reads every inbound ticket before a person does. It detects the language, classifies the request against the team's own category list, sets a priority, attaches the account and its entitlement, merges obvious duplicates, and routes to a queue. Anything it cannot classify confidently goes to the general queue untouched.

What starts it

A ticket arrives in the helpdesk from email, chat, or the web form and sits unassigned with no category, no priority, and no owner attached to it.

What it does

  1. 01

    Detect the language, and if the team does not staff it, route to whichever queue or vendor does before anything else happens.

  2. 02

    Classify the request against the team's own category list rather than a generic taxonomy, and record the confidence alongside the label.

  3. 03

    Look up the requester, their account, and the support plan that determines which response clock applies to this ticket.

  4. 04

    Search recent tickets on the same account for the same symptom, and merge rather than opening a parallel thread on a problem already being worked.

  5. 05

    Set priority from the entitlement and the stated business impact, then start the first-reply clock the policy defines.

  6. 06

    Redact card numbers, API keys and passwords pasted into the body before the ticket becomes visible to the whole queue.

What it connects to

  • A helpdesk with trigger, view, and response-target support (Zendesk, Freshdesk, or Intercom) holding the queues and the clocks
  • The team's own help centre and its closed-ticket history, which is the corpus classification and duplicate detection actually run against
  • The billing or entitlement system, because priority depends on which plan the account is on and whether it is in renewal

How it goes wrong

  • Reading a calm, precisely written report of total data loss as low priority because the tone carries no urgency, while an angry message about a cosmetic layout bug is escalated ahead of it. Triage that keys on sentiment inverts severity.
  • Auto-replying to an unsolicited security disclosure with a help centre article. The researcher concludes nobody is reading, and the next report goes to a public forum instead of the inbox.
  • Merging two tickets that share a symptom but not a cause, so one customer's thread is closed by a fix that was never applied to their account and they have to start again from the beginning.
  • Classifying confidently into a category that no longer matches how the team is organised, which routes a real ticket to a queue nobody watches any more.

When it hands back

Any ticket naming a regulator, a lawyer, a data access or erasure request, a chargeback, or a security vulnerability, plus any account inside its notice period and any requester who has now asked the same thing twice.

Triage is classification, not resolution

These are two different jobs with two different risk profiles, and vendors price them differently because of it. Classification reads a ticket and decides where it goes. Resolution answers the customer. Classification failing means a ticket is late. Resolution failing means a customer was told something untrue by a system wearing your name.

Zendesk splits them the same way. Its intelligent triage predicts topic (formerly intent), language, sentiment and custom entities on incoming tickets, and those predictions are available on Suite and Support Professional plans and above, while using them to drive workflows requires Zendesk’s Copilot add-on. The predictions land on the ticket and feed triggers and views. Nothing is sent to the customer.

Start with classification. It is reversible, it is cheap, and it produces the labelled history that any later resolution attempt needs.

The cost of each unit

A classification pass reads the ticket body and a category list. Two thousand input tokens and a two hundred token structured label is a fair working assumption. Anthropic prices Claude Haiku 4.5 at one dollar per million input tokens against five dollars per million output. Run the two halves separately and they come to $0.002 and $0.001, so about a third of a cent per ticket, or roughly fifteen dollars a month across five thousand tickets.

Resolution is priced in a different unit entirely. Intercom publishes Fin at $0.99 per outcome, where an outcome is a resolution or a completed procedure, handoffs included, charged once per conversation regardless of how many questions were answered. Intercom’s own Copilot is listed separately at $29 per seat per month billed annually. The gap between a third of a cent and ninety-nine cents is not vendor margin. It is what it costs to be accountable for the answer rather than for the label.

Confidence has to be a first-class output

A triage agent that always emits a category will always be wrong on the tickets that matter, because the hardest tickets are the ones that fit no category. The correct behaviour on low confidence is to route to the general queue with no label at all, which costs a person a glance. The incorrect behaviour is to pick the nearest label, which costs nobody anything today and costs the customer the wait until someone notices.

Two bands is usually enough: above the threshold, apply the label and route; below it, leave it unclassified and let it surface in the human triage view. Log both, and review the low-confidence pile weekly. That pile is the map of where the category list has drifted away from what customers actually write in.

Priority is an entitlement question first

Severity is not a property of the message. It is a property of the account, the plan, and what stopped working. A one-line email from an enterprise customer saying “checkout is returning 500” outranks four paragraphs of frustration about an export button, and no amount of sentiment analysis will get there. Read the entitlement, read the stated impact, and treat tone as a tiebreak rather than an input.

What the agent must never touch

Some categories are not triage problems at all. A data subject access request and a data erasure request start statutory clocks. A security vulnerability report needs a named human within hours and needs the reporter to know a person read it. A chargeback notice has a bank deadline. An account in its notice period is a commercial conversation. In each case the correct agent behaviour is the same: flag, route to a named person, send nothing to the customer, and stop.

The redaction step belongs in the same category of non-negotiable. Customers paste card numbers, session tokens and passwords into support tickets constantly, and once that lands in a shared queue it is in the search index, the exports, and the analytics warehouse. Strip it on arrival, before triage, not after.

Where this job differs

Apply