Building a Multi-Agent n8n Workflow That Handles Customer Support End-to-End

Most customer support automation fails at the same point: it handles the easy tickets fine and falls apart on anything that requires context, history, or judgment. The result is a system that deflects 30% of tickets automatically but requires a human to clean up after the other 70% — plus the 30% it mishandled.

The architecture I’m going to walk through is different. It was built for a B2B SaaS client with a 50,000-user base, a support team of 8, and a ticket volume that was growing 40% quarter-over-quarter. After deployment, 78% of tickets were fully resolved without human intervention. The remaining 22% were escalated with full context — no wasted back-and-forth.

The Architecture Overview

The system uses four specialized agents running inside n8n, coordinated by a routing layer that decides which agent handles each ticket. This is the key insight: instead of one agent trying to do everything, you have purpose-built agents that are very good at specific tasks.

The four agents:

1. Classifier Agent — Reads the ticket and assigns it to one of six categories: billing, technical bug, feature request, account access, usage question, or escalation required.
2. Context Agent — Queries the knowledge base (Supabase + Pinecone), fetches the customer’s account history from the CRM, and builds a structured context object.
3. Resolution Agent — Uses the category + context to draft a response. Has different system prompts per category, calibrated over 300+ evaluated examples.
4. QA Agent — Reviews the drafted response against quality criteria before it’s sent: tone, accuracy, completeness, and whether it actually answers the question asked.

Building It in n8n

Trigger & Ingestion

The workflow starts with a webhook trigger — Zendesk fires an event whenever a new ticket is created or reopened. The first node normalises the payload into a consistent structure regardless of whether it came from email, web form, or the in-app chat widget.

{
  "ticketId": "ZD-48291",
  "channel": "email",
  "subject": "Can't access my account after SSO change",
  "body": "...",
  "customer": {
    "email": "user@company.com",
    "plan": "Growth",
    "accountAge": 847
  }
}

Classification

The normalised ticket goes to an OpenAI node configured with the Classifier Agent prompt. The model is GPT-4o-mini here — fast and cheap, since classification is a low-complexity task.

The prompt enforces JSON output with a strict schema. We use response_format: { type: "json_object" } and validate the output against a Zod schema in the next node. If validation fails, the ticket is routed to human review — never silently dropped.

Output schema:
{
  category: "billing" | "technical_bug" | "feature_request" | 
            "account_access" | "usage_question" | "escalation",
  confidence: 0.0–1.0,
  sentiment: "neutral" | "frustrated" | "urgent",
  summary: string (max 80 chars)
}

Tickets with confidence below 0.75 get a secondary classification pass with a different prompt. If the second pass also returns below 0.75, the ticket routes to human review with both classification attempts attached.

Context Retrieval

The Context Agent runs three parallel queries:

• Knowledge base search (Pinecone): Embeds the ticket summary and retrieves the 5 most semantically similar resolved tickets + 3 most relevant knowledge base articles.
• CRM lookup (HubSpot API): Fetches account status, plan tier, recent interactions, open invoices, and assigned CSM.
• Product status (internal API): Checks whether there are any active incidents or known bugs relevant to the customer’s reported issue.

These run in parallel inside an n8n Parallel node — total retrieval time is under 800ms. The results are merged into a context object passed to the Resolution Agent.

Resolution & QA

The Resolution Agent receives the ticket, category, and context. Its system prompt is category-specific — the prompt for account_access is tuned to always include specific remediation steps, while billing prompts are tuned to never make promises about refunds without flagging for human approval.

The QA Agent is the last gate. It receives the drafted response and scores it against five criteria, each on a 1–5 scale:

1. Does the response actually answer the question asked?
2. Is the tone appropriate given the sentiment score?
3. Are all technical claims accurate based on the retrieved context?
4. Is it the right length? (Not too long, not a brush-off)
5. Does it avoid making commitments we can’t keep?

Responses scoring below 18/25 are flagged for human review with the QA scores and reasoning attached. Responses scoring 18–21 are sent but logged for daily review. Responses scoring 22+ are sent automatically.

Results After 90 Days

The CSAT improvement was the result we were least confident about going in. The hypothesis was that speed would compensate for any perceived impersonality of AI responses. In practice, customers don’t care if a response is AI-generated — they care if it actually solves their problem.

What We’d Do Differently

Start with a shadow mode deployment — run the automation in parallel with your existing process for two weeks, comparing automated responses against human responses without sending the automated ones. This gives you calibration data before you’re in production.

Build the escalation path before you build the automation. Know exactly where tickets go when the system isn’t confident, and make sure that path is fast and context-rich. The worst outcome is a frustrated customer who already tried the automated response and now has to start over with a human who has no context.

Review QA failure patterns weekly. The patterns tell you where to improve your prompts, your knowledge base, or your training data — and that compounding improvement is where the long-term value lives.