AI Support Ticket Triage System — Automatically Classify, Prioritise and Route Every Support Request Before a Human Touches It
Built by ViperVibe ·
About this build
A Claude powered workflow that reads every incoming support ticket, classifies it by type and urgency, extracts key information, matches it to relevant documentation, generates a suggested first response and routes it to the right team member — all before any human has opened the ticket.
What was built
Built this after watching a 3 person support team spend the first 90 minutes of every morning just sorting through overnight tickets before they could start actually helping anyone. The triage itself was creating a backlog before the day had even started. Here is exactly how the workflow runs: Step 1 — Ticket ingestion Every new ticket submitted via Intercom or Freshdesk triggers an n8n webhook. The full ticket content including subject, body, any attachments converted to text and the customer's account history gets pulled into the workflow. Step 2 — Classification via Claude Claude reads the full ticket and classifies it across four dimensions simultaneously. Category — what type of problem is this. Options include billing, technical bug, feature request, account access, how-to question, complaint and escalation. Urgency — rated 1 to 5 based on explicit signals like words such as urgent, broken, cannot access, losing money, and implicit signals like whether the customer is on a paid plan, how long they have been a customer and whether this is a repeat issue. Sentiment — positive, neutral, frustrated or angry. This affects how the response is drafted and whether a manager flag is needed. Complexity — simple meaning answerable from documentation, medium meaning needs a support agent, complex meaning needs engineering or a senior team member. Step 3 — Documentation matching The ticket gets searched against the company's Notion or Confluence documentation using keyword and semantic matching. If there is an existing help article, known issue thread or previous ticket resolution that matches the problem, the relevant content gets pulled into the workflow for the response generation step. Step 4 — Suggested response generation via Claude Claude generates a suggested first response for the support agent to review, edit and send. The response is not sent automatically — it is a starting point that the agent can approve with one click or edit before sending. The response is drafted in the company's support tone, references the specific issue described rather than being generic, and includes any relevant documentation links found in Step 3. Step 5 — Routing and notification Based on the classification, the ticket gets assigned to the right team member in Intercom or Freshdesk and a Slack notification is sent to that person with a summary of the ticket, its urgency score, the customer tier and the suggested response. High urgency tickets also ping the support manager. Step 6 — Airtable logging Every ticket and its classifications get written to Airtable. This builds a dataset over time showing ticket volume by category, average urgency, most common issues and response time by ticket type. After 6 weeks of data this becomes genuinely useful for product prioritisation — the feature request category alone showed us three recurring requests we had not identified as patterns before. What broke during development: The urgency scoring was inconsistent early on because I was asking Claude to rate urgency as a number without defining what each number meant. Fixed by giving Claude an explicit rubric — urgency 5 means revenue impact or complete product failure, urgency 4 means significant workflow disruption, urgency 3 means moderate inconvenience with a workaround available, and so on. Consistency improved dramatically. The documentation matching was initially returning too many results and overwhelming the response prompt. Fixed by limiting matches to the top 2 most relevant documents and instructing Claude to only reference documentation if it directly answers the question rather than broadly relates to the topic. The suggested response tone was too formal for the brand. Fixed by including 5 examples of approved previous responses as style anchors in the Claude prompt — same approach as the newsletter writer but for support voice. Results after 8 weeks: Average triage time per ticket dropped from 4 minutes to under 30 seconds. The team now spends that time on actual resolution rather than classification. First response time improved by 61 percent because agents are starting from a drafted response rather than a blank page. The Airtable analytics surfaced a billing confusion issue that was generating 23 percent of all tickets but had never been identified as a pattern because it was spread across different agents. The suggested response approval rate is 71 percent meaning agents send the Claude draft with minor edits 7 out of 10 times. The other 30 percent they edit more substantially or rewrite, which is exactly how it should work — the human stays in control of the resolution. What I would build next: Auto-resolution for the simplest ticket types — password reset requests, invoice copy requests and basic how-to questions that have a direct documentation answer. These represent about 18 percent of total ticket volume and could be fully resolved without human involvement. Will only build this after running the current system for another 3 months and confirming the classification accuracy is high enough to trust with no human review.