← All work

n8n · Automation breakdown

Support triage & SLA engine

Two triggers, parallel enrichment, and a tool-calling agent that scores every ticket before a 4-way router sends it to on-call, a human-approved refund draft, a RAG self-serve reply, or a review queue.

Platform
n8n
Scope
23 nodes
Triggers
2 triggers
Pattern
human-in-the-loop
nSupport Triage & SLA Engine
ActiveSave
Stage 1 — Intake & sanitation
Webhook receives the ticket, Set normalizes 14 fields, and a Code node redacts PII before anything touches an LLM.
Stage 2 — Parallel enrichment
Account, billing, and prior-ticket context fetched concurrently, then merged into one payload.
Stage 3 — Agent classification
Tool-calling agent scores sentiment, urgency, and refund eligibility against policy, returning strict JSON for the router.
Stage 4-5 — Resolve & log
Four tiers: P1 pages on-call, billing drafts a refund for human approval, self-serve answers from RAG, the rest queues for a human. All paths log.
Stage 6 — SLA sweeper (separate trigger)
Every 15 min, batch-scan open tickets for SLA breach, escalate to the owner's manager, and roll a weekly digest.
P1 · urgentbillingself-serveunclassified
Zendesk Webhook
POST /ticket.created
Normalize Payload
set: 14 fields
{ }
Redact PII
code: regex + hash
Postgres
getAll: account
$
Stripe
get: subscription
Vector Store
similaritySearch
Merge Context
combineAll
Triage Agent
tools: 3 · structured
Route by Tier
mode: rules · 4
!
PagerDuty
create: incident
Slack #oncall
sendAndWait
Draft Refund Reply
chain: llm
Approve in Slack
sendAndWait
RAG Answer
chain: retrievalQA
Send Reply
zendesk: comment
Human Queue
sheet: appendOrUpdate
Log to Warehouse
bigQuery: insert
SLA Cron
*/15 * * * *
Find Breaching
postgres: query
Loop Batches
splitInBatches: 25
Escalate Owner
if: age > sla
Notify Manager
slack: post
Weekly Digest
gmail: send
Chat ModelGPT-4oMemoryPostgres ChatToolOrder LookupToolRefund PolicyModelEmbeddingsVector StoreQdrant

Scroll horizontally to pan the full canvas.

The problem

A support inbox where every ticket looks equally urgent until a human reads it. The team was triaging by hand, refunds waited on whoever was awake, and SLA breaches were discovered after the customer complained rather than before.

Stage by stage

How it actually runs.

01

Intake & sanitation

A webhook catches ticket.created from the helpdesk. A Set node normalizes fourteen fields into a stable shape so downstream nodes never depend on the vendor's payload, and a Code node strips and hashes PII before anything reaches a language model. That ordering is deliberate — redaction happens before the first LLM call, not after.

02

Parallel enrichment

Three lookups fire concurrently rather than in sequence: account record from Postgres, live subscription and payment state from Stripe, and semantically similar past tickets from a vector store. A Merge node combines all three into one payload, so the classifier sees the customer's full context instead of just the message text.

03

Agent classification

A tool-calling agent scores sentiment, urgency, and refund eligibility against written policy. It has its own model, Postgres-backed chat memory, and two tools — an order lookup and a refund-policy retriever — so it can check facts instead of guessing. Output is constrained to strict JSON, which is what makes the next step routable rather than a paragraph someone has to read.

04

Four-way routing

P1 incidents create a PagerDuty incident and page on-call. Billing issues get an empathetic refund reply drafted by the model, then wait on a Slack approval before anything is sent — the model proposes, a human commits. Self-serve questions are answered from a retrieval chain over the docs. Anything the agent could not classify confidently goes to a human queue rather than being guessed at.

05

Convergence & logging

Every branch, including the unclassified one, writes to the same warehouse table. That single convergence point is what makes the weekly reporting trustworthy — there is no path through the workflow that silently exits without a record.

06

SLA sweeper

A completely separate schedule trigger runs every fifteen minutes, queries open tickets approaching their SLA, processes them in batches of twenty-five to stay inside API limits, and escalates to the owner's manager. It shares the same log table, so breaches show up in the same weekly digest.

Stack

n8n (self-hosted)OpenAI GPT-4oPostgresQdrantStripeZendeskPagerDutySlackBigQuery

Decisions that matter

  • PII redaction runs before the first model call, not after.
  • Refunds require a human approval step — the model drafts, a person sends.
  • Low-confidence classifications route to a person instead of a default branch.
  • Batching on the sweeper keeps the workflow inside vendor rate limits at volume.

Other automations

Start a project

Have a business that needs a system, not just a site?

adrian.afable@gmail.comUsually replies within a day