How to Build an AI Customer Support Workflow with n8n and Ollama

10 hours ago

6 min read

This practical build plan shows how to automate the repetitive first pass on customer support requests while keeping people in control of customer-facing replies. A request arrives, an AI model classifies and summarizes it, a suggested response is prepared, and a support employee reviews it before any reply is sent.

WHAT YOU WILL BUILD

A POST request enters n8n through a webhook. Ollama processes the message using a locally hosted model. A validation step checks the returned fields and marks questionable results for manual review. The workflow then records the ticket and sends an internal notification. It does not send an AI draft directly to the customer.

Workflow: Support form → n8n Webhook → Ollama → Validate output → Google Sheets tracker → Internal Gmail notification → Human review before reply.

TOOLS AND PREREQUISITES

• n8n for workflow automation

• Ollama for a locally hosted language model and HTTP API

• Google Sheets for the ticket tracker

• Gmail for an internal team notification

• A form or service that can send JSON

Install and start Ollama on a machine reachable from the n8n server. Pull a model supported by your machine, such as qwen2.5:1.5b, and confirm the Ollama API is available. If n8n and Ollama run in separate containers, localhost inside n8n points to the n8n container; use the Ollama service name or a reachable host address instead.

1. CREATE THE TICKET TRACKER

Create a Google Sheet named AI Customer Support Tracker with these headers in row 1: Ticket_ID, Customer_Name, Customer_Email, Customer_Message, Category, Priority, Summary, AI_Suggested_Response, Validation_Status, Status, Created_At, Reviewed_By.

Use these categories: Billing, Order Status, Technical Support, Product Information, Complaint, Other. Use Low, Medium, or High for priority. Set new tickets to Pending Review. Keep the original message and AI suggestion in separate columns. Restrict sheet access to support staff; the workflow sends message content to Sheets and the internal notification service even though model inference is local.

2. ADD THE WEBHOOK TRIGGER

Create a workflow named AI Customer Support Automation. Add a Webhook node with HTTP Method POST, Path customer-support, and response mode Using Respond to Webhook Node. Add a Respond to Webhook node with a small JSON acknowledgement such as { "received": true, "status": "Pending Review" }.

Use this synthetic request while configuring the workflow:

{

"customer_name": "Rahul",

"customer_email": "rahul@example.com",

"message": "My order has not arrived. It was supposed to be delivered yesterday."

}

Do not use real customer data during development. Before sharing a live webhook URL, add suitable authentication, rate limiting, access controls, and retention rules.

3. ASK OLLAMA TO CLASSIFY AND DRAFT

Add an HTTP Request node after the webhook. Set Method to POST, URL to http://localhost:11434/api/generate (replace the host if Ollama runs elsewhere), enable Send Body, choose JSON, and request a JSON response.

Use an expression for the JSON body so the incoming message is inserted as a value rather than concatenated into raw JSON:

={{ {

model: "qwen2.5:1.5b",

stream: false,

format: "json",

prompt: "Classify the customer support message. Return JSON with category, priority, summary, and suggested_response. category must be Billing, Order Status, Technical Support, Product Information, Complaint, or Other. priority must be Low, Medium, or High. Never invent order details, refund approvals, delivery dates, or company policies. If information is missing, ask for clarification. Message: " + $json.body.message

} }}

The Ollama /api/generate response places the generated text in a response field. Confirm the actual output shape in your n8n version before mapping later nodes.

4. VALIDATE THE MODEL OUTPUT

Add a Code node after the HTTP Request. Parse response as JSON and check that category belongs to the approved list, priority is Low/Medium/High, suggested_response is non-empty, and the suggestion does not make an unsupported refund, delivery, or policy promise. Retain the original message and customer details from the Webhook node.

Set validation_status to valid only if every check passes; otherwise use manual_review. Keep the status Pending Review in both cases. Route invalid JSON, missing fields, or suspicious commitments to manual review instead of dropping the request.

Example JavaScript logic; adjust the node references and field paths to match the actual n8n input:

const categories = new Set(["Billing", "Order Status", "Technical Support", "Product Information", "Complaint", "Other"]);

const priorities = new Set(["Low", "Medium", "High"]);

const request = $items("Webhook")[0]?.json?.body ?? {};

return $input.all().map((item) => {

let ai = {};

try { ai = typeof item.json.response === "string" ? JSON.parse(item.json.response) : item.json.response ?? {}; } catch {}

const suggestion = typeof ai.suggested_response === "string" ? ai.suggested_response.trim() : "";

const promise = /\b(refund (is|has been) approved|will be delivered (today|tomorrow)|guaranteed delivery)\b/i.test(suggestion);

const valid = categories.has(ai.category) && priorities.has(ai.priority) && suggestion.length > 0 && !promise;

return { json: { ticket_id: "GI-" + Date.now(), customer_name: request.customer_name ?? "", customer_email: request.customer_email ?? "", customer_message: request.message ?? "", category: categories.has(ai.category) ? ai.category : "Other", priority: priorities.has(ai.priority) ? ai.priority : "Medium", summary: ai.summary ?? "", suggested_response: suggestion, validation_status: valid ? "valid" : "manual_review", status: "Pending Review", created_at: new Date().toISOString(), reviewed_by: "" } };

});

This is a first-pass check, not a guarantee that the suggested reply is correct. A person still needs to compare it with the original enquiry and the organization's current policies.

5. APPEND THE REQUEST TO GOOGLE SHEETS

Add a Google Sheets Append Row operation and select the tracker and worksheet. Map each column from the validated Code node output. Do not set the status to Approved automatically. If the Google Sheets credential or target tracker is unavailable, connect it before testing the full workflow; do not send ticket content to an unreviewed destination.

6. SEND AN INTERNAL NOTIFICATION

Add a Gmail operation that sends an internal notification to the designated support-team address, not to the customer. Include Ticket ID and tracker link, customer name and original message, category, priority and validation status, suggested response, and a reminder that the reply is pending human review. Use the approved team mailbox and least-privilege credentials.

7. KEEP HUMAN APPROVAL IN THE LOOP

Use the tracker as the first-version review queue. A support employee should approve, edit, reject, or escalate the suggestion and record their name and decision. If a later version sends customer replies, add a separate gate that checks an explicit approved status and uses the reviewed response, not the original AI suggestion.

8. TEST WITH SYNTHETIC REQUESTS

Run the workflow with synthetic messages and record the actual results. Expected categories: “I was charged twice for my purchase.” → Billing; “Where is my delivery?” → Order Status; “I cannot log in to my account.” → Technical Support; “What are the features of this product?” → Product Information; “I am unhappy with the service I received.” → Complaint.

Verify webhook fields, Ollama response parsing, validation behavior, tracker mapping, internal notification, and the manual review process. Also test malformed JSON, an unsupported category, and an AI suggestion that makes an unsupported promise. Record results; do not assume the workflow passed.

9. MEASURE USEFULNESS BEFORE EXPANDING

Track ticket volume, reviewer-confirmed classification accuracy, suggestion acceptance and edit rates, average review time, resolution time, escalations, and rejected suggestions. Compare AI categories with categories confirmed by reviewers. Use a pilot period and a baseline before claiming time savings or service improvements.

TROUBLESHOOTING

• n8n cannot reach Ollama: confirm Ollama is running and use a hostname reachable from the n8n runtime. localhost may refer to a different container.

• Invalid JSON: inspect the raw response field, keep parse failures on the manual-review path, and never treat a parse failure as valid.

• Blank tracker values: inspect actual Webhook and Code node output and map the exact paths; payload structures can differ by n8n version.

• Duplicate tickets: add an idempotency key from the form or upstream system and check for an existing key before appending.

• Invented commitments: keep customer replies behind human review and update the policy checks to match your support rules.

PRIVACY AND OPERATING LIMITS

Local inference can keep the model call on infrastructure you control. It does not make the whole workflow private: Sheets, Gmail, webhook logs, n8n execution history, and backups may still contain customer information. Review access and retention across each service. Use minimum necessary data and synthetic inputs for initial testing.

This post describes a build plan and should be treated as an implementation draft until the workflow has been run successfully and screenshots of the actual nodes and tracker have been captured. No client case study or performance result is claimed.

FREQUENTLY ASKED QUESTIONS

Does the workflow automatically reply to customers? No. It creates a suggested response for a human reviewer. Keep any later send step behind an explicit approval gate.

Does local Ollama mean the whole workflow is private? No. Customer data can still pass through n8n, Google Sheets, Gmail, execution logs, and backups.

What if Ollama returns invalid JSON? Mark the ticket for manual review and preserve the original message. Do not send an invalid or unreviewed answer.

Can I use a different model? Yes, if your Ollama installation supports it and your hardware can run it. Re-test classification and response quality after changing models.

What should I measure in a pilot? Reviewer-confirmed accuracy, suggestion acceptance and edit rates, review time, resolution time, and escalations. Do not claim savings without a baseline and observed results.

How to Build an AI Customer Support Workflow with n8n and Ollama

Recent Posts

Comments