Every incoming support ticket gets read the moment it arrives, not queued for a human to eyeball first. A webhook receives the ticket, Claude reads it for tone and business impact, tiers it escalate, standard, or self-serve, and drafts the tier-appropriate response itself — an urgent internal page, a support reply, or a self-serve answer — before archiving and returning the result immediately.
Claude reads the ticket for tone, business impact, and repeat-contact signals — not just keyword matching — then assigns exactly one tier.
One straight path from intake to triage, then a three-way fork on the tier. All three land in the same archive and response.
support_tickets_triaged Data Table.The tickets below are made-up test data, not real customers. The tiers, sentiment reads, and drafted responses are genuine, unscripted output — each one is what Claude actually produced from running that ticket through the live workflow.
The same AI call that tiers the ticket also drafts what happens next, matched to the tier: escalate gets an urgent internal page, standard gets an empathetic support reply with a real next step, and self-serve gets a direct answer pointing to the specific help-center article. Nothing is left as a bare tag — even the calmest question above got a real drafted reply.
support_tickets_triaged? It's a Data Table — a lightweight database built directly into this n8n workspace, not a separate external system. It lives inside this n8n project, viewable in n8n's own Data Tables screen and reachable by any other workflow in the same project. It isn't exposed to the public internet on its own — the only way anything outside n8n sees this data is through what a workflow deliberately sends back out, like the drafted responses above.
| ticket_id | customer | tier | customer_tier | sentiment | reasoning |
|---|---|---|---|---|---|
| TKT-4401 | Priya Nair | escalate | Enterprise | frustrated | Repeat contact, blocked payroll, explicit churn-risk language. |
| TKT-4405 | Aisha Kone | escalate | Enterprise | frustrated | Possible account breach plus an unauthorized $4,200 charge. |
| TKT-4402 | Marcus Webb | standard | Pro | neutral | Reproducible export bug, not urgent, has a workaround. |
| TKT-4407 | Lena Kowalski | standard | Pro | neutral | Recurring integration disconnect, not blocking, no urgency. |
| TKT-4403 | Sofia Ramirez | self_serve | Free | neutral | Password reset — fully covered by existing documentation. |
| TKT-4404 | Devon Clarke | self_serve | Free | neutral | Billing-cycle question — a standard documented answer. |
Nothing here runs on a manual trigger in production. A real ticket has to enter this pipeline the moment it's submitted, and the result has to land somewhere a person actually sees it — usually the help desk system of record.
Zendesk, Intercom, and Freshdesk all ship their own routing rules and macros, and at a company that already has those tuned well, this workflow isn't a replacement for them.
Where a custom pipeline like this earns its place: native routing is typically keyword or field-based (a form dropdown, an SLA tag) rather than reading tone and business context the way this does, drafting a specific reply is usually a separate macro someone still has to pick and edit, and cross-tool judgment calls — like weighing "Enterprise plus repeat contact plus a deadline" together — are hard to express as rigid routing rules. This build is the shape you reach for when the native rules can't express that judgment, or when the drafted response needs to be genuinely tailored rather than a canned macro.