# How we automated customer support at Alasco with n8n

- URL: https://alasco.tech/2026/04/27/automating-customer-support-with-n8n/
- Date: 2026-04-27T00:00:00.000Z
- Authors: Moritz Koberling, Julia Bastian
- Description: How a two-person team at Alasco built an AI-powered customer support automation using n8n, Snowflake Cortex Search, and Google Gemini, going from idea to production in five days and saving 20+ hours per week.

Every customer support team knows the feeling. The same questions keep coming in, phrased slightly differently each time, and someone has to write a thoughtful, accurate response from scratch. At Alasco, our Customer Support team handles hundreds of tickets per week across a complex B2B SaaS product that manages construction budgets, invoices, financing, and ESG compliance for real estate companies. The domain is dense and the terminology is specific. Every wrong answer erodes trust.

We had already built an internal AI assistant, but adoption was uneven. Not every support agent had integrated it into their daily workflow. So instead of asking people to change their habits, we decided to bring the AI directly into the ticket pipeline. Two people built it in five days using a single n8n workflow. The result: 85% accuracy on draft responses, 20+ hours saved per week for the support team, and a system that gets smarter with every ticket it processes.

## The problem we were solving

Our support team was spending a significant portion of their week on tickets that, in hindsight, had been answered before. Sometimes dozens of times. The answers lived in three places: past ticket responses in Zendesk, help center articles (in both German and English), and the heads of experienced support agents.

The challenge was not just "use AI to answer tickets." Domain-specific B2B support is fundamentally different from consumer chatbot scenarios. Our customers ask about DIN 276 cost structures, SEPA payment exports, budget allocation hierarchies, and invoice approval workflows. A generic LLM will hallucinate confidently about these topics. We needed a system that grounds every response in evidence: past answers that worked, and documentation that is actually correct.

We also needed to keep a human in the loop. In financial software, a wrong support answer can lead to incorrect bookings or missed payment deadlines. Full automation was never the goal. *Assisted* automation was.

## How we built it: a six-stage pipeline

We chose n8n as the orchestration layer because it gave us visual workflow design, easy integration with Zendesk and Slack, and enough flexibility to embed custom logic without writing a full application. The entire pipeline runs as a single n8n workflow with six stages.

![Process overview: six-stage n8n workflow from ticket retrieval to draft response](./images/process-overview.jpg)

### Stage 1–2: retrieve and clean the ticket

When a new ticket lands in Zendesk, the workflow triggers automatically. It pulls the full ticket (including the submitter, assignee, organization, comments, and attachments) and runs it through a noise-removal step. Support tickets are messy: email signatures, legal disclaimers, forwarded threads, and quoted replies all add bulk without adding signal.

We strip names, signatures, and irrelevant formatting, then generate a short summary of the actual problem. This cleaned version becomes the seed for everything downstream. We also check whether Alasco's internal AI assistant has already generated a relevant answer and inject that into the context if available, effectively giving the pipeline a head start even before RAG kicks in.

![Stages 1 and 2: retrieving the ticket from Zendesk, then cleaning it by removing names, signatures, and noise before summarizing the actual problem](./images/stage-1-2-retrieve-transform.jpg)

### Stage 3: understand the attachments

This was one of the more technically interesting parts. A large percentage of our tickets include screenshots, PDFs, or Excel files where the customer is showing us what went wrong. Ignoring these attachments means missing critical context.

We built a branching sub-workflow that detects the file type and routes accordingly:

- **Images** (PNG, JPEG), both attached files and images embedded inline in the ticket body, are uploaded and analyzed with a vision model. The system prompt instructs the model to extract only information that is *directly relevant* to the described issue, avoiding generic image descriptions.
- **PDFs** are downloaded, analyzed, and their semantic content is extracted with the same relevance constraint.
- **Excel and Word files** are downloaded and their content is added to the context.

All extracted information is normalized into a consistent format for embedding and merged back into the ticket context. This stage alone was responsible for a meaningful jump in response quality. Many tickets are simply incomprehensible without the screenshot the customer attached.

![Stage 3: attachment analysis, a branching sub-workflow that routes images, PDFs, and Excel/Word files through separate extraction paths before merging the results back into the ticket context](./images/stage-3-attachments.jpg)

### Stage 4: find similar past tickets with Cortex Search

This is the RAG core of the system. We use Snowflake Cortex Search to find historically similar tickets. The cleaned ticket text is sent as a query, and Cortex Search returns a ranked list of similar past tickets along with similarity scores.

We apply a quality threshold: only tickets with a similarity score above 0.62 make the cut. This number was not arbitrary. We tested different thresholds and found that below 0.62, the retrieved tickets were topically adjacent but not similar enough to produce useful draft responses. Above 0.7, we were filtering out too many genuinely helpful matches.

For every ticket that passes the threshold, we retrieve the actual response that our support team gave at the time. This is key: every match returns both the question and the answer that resolved it. The system learns from what worked.

![Stage 4: Snowflake Cortex Search retrieves similar historical tickets with similarity scores, filters anything below 0.62, then pulls the first agent reply for each kept ticket](./images/stage-4-cortex-search.jpg)

### Stage 5: match help center articles

In parallel, we query Alasco's Zendesk help center for articles relevant to the ticket. This runs in two parallel paths (one for English articles, one for German) because our customer base uses both languages and the ticket language determines which help center content is most useful.

Each candidate article is scored for semantic similarity to the ticket, and only articles that meaningfully match are kept. The selected articles serve two purposes: they provide additional grounding for the response, and they give the support agent ready-made links to send to the customer.

![Stage 5: parallel English and German paths that fetch help center articles, score them against the ticket, and keep only the meaningfully matching ones](./images/stage-5-helpcenter.jpg)

### Stage 6: draft the response and close the loop

With all the context assembled (cleaned ticket, attachment analysis, similar past answers, and relevant help center articles), we generate the draft response using Google Gemini. The system prompt is carefully scoped: the model acts as a CE Support assistant at Alasco GmbH, must be concise and professional, and must start with a greeting.

**The draft is never sent directly to the customer.** Instead, it is:

1. **Posted to Slack** in the support team's channel, where the assigned agent can review it in the flow of their normal work.
2. **Added as an internal note in Zendesk**, so the agent can review and send it with one click, or edit it first.
3. **The original ticket is stored in the vector database**, so the system's knowledge base grows with every ticket processed.

This three-pronged output keeps the human in the loop while minimizing friction. The agent does not need to open a separate tool, copy-paste from a chatbot, or switch contexts. The draft appears exactly where they are already working.

![Stage 6: Google Gemini drafts the reply, posts it to Slack for review, adds it as an internal note in Zendesk, and writes the original ticket into the Snowflake vector database](./images/stage-6-output.jpg)

## What 85% accuracy actually means

We should be honest about what "85% accuracy" means in practice, because it is easy to over-claim.

It means that in roughly 85% of cases, the draft response is good enough to send with minor edits or no edits at all. The remaining 15% are tickets where the system either retrieves the wrong context, misunderstands the problem (often because the ticket is genuinely ambiguous), or encounters a question that has never been asked before.

The system is notably weaker on edge cases that involve recent product changes not yet reflected in the help center or the ticket history. It is also weaker on multi-part tickets where the customer is asking about several unrelated issues in a single message. These are areas we are actively working on.

## The self-improving loop


Early on, the system performed noticeably worse on ESG-related tickets because our historical ticket volume in that product area was smaller. As the team processed more ESG tickets through the pipeline, accuracy for that category climbed steadily. The system rewards usage: the more you use it, the better it gets.

## Five days, two people

The entire project, from first n8n node to production workflow, took five days of focused work by Moritz Koberling and Julia Bastian. Neither of them is a machine learning engineer. Moritz works as GTM Engineer in our RevOps team; Julia is on the Customer Experience side. They combined domain expertise (Julia knows exactly what a good support response looks like) with technical execution (Moritz built the workflow and integrations).

This is a pattern we have seen repeatedly at Alasco: effective AI automation does not require a dedicated ML team. It requires domain expertise applied to a clear problem with pragmatic tooling. n8n, Snowflake Cortex Search, and Google Gemini are all off-the-shelf components. The hard parts were the prompt engineering, the similarity threshold tuning, the attachment handling logic, and the workflow design that keeps humans in the loop without adding friction.

## What we would do differently


We would probably build a lightweight evaluation framework earlier. Right now, "85% accuracy" is based on agent feedback and manual spot checks. A more systematic evaluation (comparing draft responses against actual sent responses) would give us better signal on where the system is improving and where it is plateauing.

## Takeaways for other teams

1. **Start with the workflow, not the model.** The LLM is the least interesting part of this system. The value comes from assembling the right context *before* the model sees it: cleaned tickets, analyzed attachments, similar past answers, relevant documentation.

2. **Set a similarity threshold and test it.** RAG without quality filtering retrieves noise. Our 0.62 threshold was the result of experimentation, not intuition. Your threshold will be different. Find it empirically.

3. **Keep the human in the loop, but make the loop frictionless.** Posting drafts to Slack and as Zendesk internal notes means agents review the output in tools they already use. Adoption was immediate because we did not ask anyone to change their workflow.

4. **Build the feedback loop from day one.** Storing the new tickets back into the vector database means the system improves automatically. This is the difference between a static prototype and a production system.