Founder of Erudience. Head of AI at Absolute Intelligence UK. Ships production n8n and voice AI systems for UK and international teams.
Claude triages support tickets by classifying intent and urgency, pulling relevant knowledge base context, and drafting a reply for human review, all before a support agent opens the ticket. This cuts time to first response without removing human judgement from what actually gets sent. The pipeline is: classify, retrieve, draft, route to a human, log the outcome against the prompt version that produced it.
Triage means deciding what a ticket is about, how urgent it is, and who or what should handle it, before any reply gets drafted. Done well with an LLM in the loop, triage removes the slowest and most repetitive part of a support queue without touching the part that actually needs a human: judgement on anything that affects a customer's money, access, or trust.
The pattern below is the one I ship for clients running Freshdesk, Zendesk, or Intercom. It assumes an assisted operator model throughout: Claude drafts and classifies, a human reviews and sends. Nothing goes to a customer unreviewed in the first months of any deployment.
What triage actually means in a support queue
Triage is not answering the ticket. It is deciding, in the first ten seconds after a ticket lands, three things: what category it falls into (billing, bug, how-to, churn risk, urgent), how urgent it genuinely is, and which queue or person should own it. Get this right and an agent opens their queue to work that is already sorted. Get it wrong and the agent spends the first part of every ticket doing the sorting themselves.
This is a strong first use case for an LLM precisely because the cost of a wrong classification is low (a ticket lands in the wrong queue, gets reassigned) while the volume is high (every single ticket needs it). Compare that to drafting a final reply, where a wrong answer reaches a customer directly. Triage is the safe end of the automation spectrum to start on.
The pipeline: classify, retrieve, draft, route, log
New ticket lands via webhook from Freshdesk, Zendesk, or Intercom into n8n. Claude receives the ticket body plus recent conversation history and returns a structured classification: category, urgency, sentiment, and a confidence score, using tool calling or structured outputs rather than parsing free text.
For anything above a confidence threshold, the workflow pulls relevant knowledge base articles or past resolved tickets on the same topic (a simple vector search over your help centre content is enough for this, it does not need a dedicated RAG platform for most support volumes) and passes that context back to Claude to draft a first response.
The draft, the classification, and the confidence score all land back in the helpdesk as an internal note or a draft reply, never sent automatically. A human agent reviews, edits if needed, and sends. Every action, human or model, gets logged against the prompt version that produced it, so a bad week of responses can be traced to a specific prompt change rather than a vague sense that quality dropped.
Why Claude specifically, for this step
Claude's strength here is instruction following on structured outputs and staying grounded in the retrieved context rather than inventing an answer when the knowledge base does not cover the question. For triage and drafting, that matters more than raw creativity. A model that says 'I do not have enough information to answer this confidently, escalating' is more useful in a support queue than one that always produces something plausible sounding.
For simple classification alone (is this billing or technical, how urgent is this), a smaller or cheaper model is often good enough and worth using to control cost at high ticket volume. Claude earns its cost on the drafting step, where getting the tone and the specific detail right actually changes whether the agent has to rewrite the response from scratch or just approve it.
Guardrails: what never gets auto sent
Refunds, account cancellations, anything touching payment details, and any reply where the confidence score falls below your threshold all route straight to a human with no drafted reply attempting to pre-empt the decision. The model's job in these cases is context gathering (pull the account history, the payment status, prior tickets) not drafting the outcome.
Sentiment matters here too. A ticket classified as high frustration or churn risk should route to a senior agent regardless of how routine the underlying question is. An accurate but tone-deaf automated draft on an angry customer's ticket does more damage than a slower human-only response.
Every automated action needs an audit trail: which model version, which prompt version, what confidence score, what a human did with the suggestion (approved as is, edited, discarded). This is what makes the system auditable to a compliance team and debuggable when something goes wrong, rather than a black box you have to trust blindly.
Rollout: shadow mode before anything goes live
Run the classifier in shadow mode first: it processes every incoming ticket and logs its classification and draft, but agents do not see it yet. Compare the model's classification against what agents actually did with the same tickets for two to three weeks. This tells you the real accuracy rate before it touches anyone's workflow, rather than finding out in production.
Once shadow mode accuracy clears your threshold (I typically look for 85 percent or higher agreement on category and urgency before going live), turn on the internal note or draft reply for agents to see, still under full human review. Auto sending anything, even for the lowest risk categories, is a later decision made once months of reviewed drafts show the pattern is reliable, not a day one setting.
- ·Triage, not final replies, is the safe first place to put an LLM in a support queue. The cost of a wrong classification is low; the cost of a wrong sent reply is not.
- ·The pipeline is classify, retrieve context, draft, route to a human, log against the prompt version. Nothing skips the human review step in the first months of any deployment.
- ·Refunds, cancellations, payment details, and low confidence or high frustration tickets route straight to a human with no automated draft attempting the outcome.
- ·Run in shadow mode for two to three weeks before agents see any output, and measure real agreement against what agents actually did.
- ·Every classification and draft needs an audit trail tied to a prompt version, so quality drops are traceable rather than a vague feeling something changed.
Frequently asked
Does this work with Freshdesk, Zendesk, and Intercom equally well?+
Yes. The pattern is helpdesk agnostic. n8n handles the integration layer against whichever platform's API or webhooks you use, so the classification and drafting logic does not change based on which helpdesk you run.
How long does a first triage system take to build?+
A focused classification and drafting pipeline for one or two ticket categories is typically three to five weeks from scoping to shadow mode, including the two to three week shadow mode measurement period before agents see any output.
Will this replace support agents?+
No. The pattern that holds up is assisted operator: the model drafts and classifies, humans review and send. Volume per agent goes up because the slow, repetitive first pass is handled, but headcount reduction is not the target and rarely the outcome in the first year.
What happens when the model gets a classification wrong?+
It gets reassigned by the agent like any misfiled ticket, and the mistake is logged. If a specific type of error recurs, the fix is almost always adjusting the prompt or adding a missing example to the knowledge base, not abandoning the approach.
Do we need a vector database for the retrieval step?+
Not for most support volumes. A vector column inside your existing Postgres or Supabase database, searched with pgvector, is enough until you are indexing tens of thousands of documents. A dedicated vector database becomes worth the operational overhead past that scale, not before it.
How do you handle data privacy with customer ticket content going to Claude?+
Ticket content is sent per request through Anthropic's API under their standard data handling terms, not used for model training by default on API traffic. For regulated clients, PII redaction happens before the API call for any field not needed for the classification or draft, and retention policy on logs is set to match the client's existing data policy.
Further reading and references
Related work on this site, and the tools and profiles referenced above.
Get new guides like this one
Whatever I ship next, straight to your inbox. No noise, unsubscribe any time.
