Pre-Sorting Email Support With AI: Our Setup at nano

Every morning there were 30 to 50 unread support emails sitting in the nano inbox, all jumbled together: returns next to praise, urgent complaints next to spam. If you want to automate support emails, that jumble is your real opponent. The individual reply is the easy part.

So at nano we started with pre-sorting and left automatic replies for later. The AI reads, categorises and writes drafts. A human approves. In this article I show you the complete setup, including the things that went wrong.

The starting point at nano

Across our three brands nano, mate and MUSTAX, about 150 to 200 customer requests come in per week. Too much to handle on the side, too little for a full-time position. The classic agency reflex would be: put a chatbot on it, done. We deliberately did not do that.

Our goal was a different one: no customer should ever get a bad automatic reply. At the same time we did not want to read, classify and type every email from scratch. The solution in between is called pre-sorting with approval. The technical term is human in the loop, meaning a person stays in the loop and has the final word.

Step 1: every email gets classified

Every incoming email runs through an n8n workflow. n8n is an automation tool that connects systems through their interfaces, in our case Gmail, Shopify and the Claude API, the programming interface to the language model.

The AI reads the email and assigns two labels:

• Category: return, shipping question, product question, complaint, invoice topic or spam.
• Urgency: normal or urgent. Urgent means, for us: angry tone, high order value or a second follow-up on the same topic.

That sounds unspectacular, and it is half the win. The categorisation sits so reliably that we stopped checking it daily. Instead of a chaotic inbox we see sorted stacks. Complaints first, spam never.

The biggest stack is always the same one, by the way: "where is my parcel?" makes up around 40 percent of all requests. We handle that category separately, as described in the article on automating WISMO requests.

Step 2: the AI writes a draft

For every email that is not spam, the AI writes a reply draft. For that it gets context:

• the customer's order data from Shopify
• our policies, for example return windows and goodwill rules
• a collection of vetted standard replies as a tone template

The draft never reaches the customer. It reaches us, as a finished proposal attached right to the email.

Step 3: a human approves

We read the draft, adjust it or rewrite it, then send. For standard cases that takes seconds. For special cases we write ourselves, with all the data already on the table.

The effect in numbers, measured across our brands:

The writing work has dropped clearly, because we only review and send. Satisfaction has gone up, with not a single complaint about slow replies since. No customer gets a rushed 10 pm reply any more.

What went wrong

Now the part that usually goes missing in agency blogs. Three things blew up on us.

Failure 1: the AI was too generous

In the first weeks the AI promised goodwill in drafts that we do not actually offer. A customer outside the return window was offered a full refund in a draft anyway. The model wanted to be friendly and read our policies generously.

We caught it during approval, so before any damage was done. That is exactly what the human in the loop is for. How we fixed it: the policies now sit word for word in the prompt, the working instruction to the model, with the addition that the AI must never name an amount on goodwill questions. A human always decides goodwill.

Failure 2: wrong customer match

Once the workflow matched an email to the wrong order. The customer had written from a different address than the one on the order, and the search fell back on a similarity in the name. The draft contained another customer's order data.

That also surfaced during approval, but it was a warning shot. Order data reaching the wrong recipient would be a data protection problem. How we fixed it: matching now requires a unique hit on email address or order number. For everything else the draft carries the note "order not clearly identified, please check manually" in place of the order data.

Failure 3: complaints sounded like a robot

With angry customers the drafts were formally correct and emotionally wrong. Smooth text blocks read like mockery when someone is genuinely furious. We spent more time rewriting than an original reply would have cost.

How we fixed it: when a complaint with a negative tone is detected, the AI writes no draft at all any more. The email only gets flagged and prioritised, and we answer by hand. What AI in support can and cannot do in general is something Damian wrote down in AI in customer service: what actually works. Our experience matches it completely.

The technical part, short and concrete

For those who want to rebuild it, our stack:

• Gmail as the inbox, connected through the Gmail API, the programming interface for automated access to email.
• n8n as the control centre, self-hosted on a small server on our side. The whole sequence lives there: fetch email, classify, enrich with data, store the draft.
• Shopify API for order data and fulfillment status.
• Claude via the API for classification and drafts. We use two separate calls: a small, fast one for the category, a more thorough one for the draft. That saves cost, because spam and standard cases never run through the expensive model.
• Slack for urgent cases. A complaint flagged as urgent does not wait in the inbox, it pings us.

The running costs are manageable: a small server plus API costs depending on volume, together a low two-digit sum per month. The real price is the build time, and the operation is cheap.

One more detail that has saved us a lot of trouble: every AI call gets logged, meaning stored with its input and output. If a draft looks odd, we can see what the model saw. Without those logs, every debugging session is guesswork.

The limits of this setup

So you place it correctly, three limitations.

This is no full automation. A human still reads every reply before sending. That is intentional, and it costs time every day. Anyone expecting zero effort will be disappointed.

The build took a while. Writing prompts, documenting policies properly, ironing out failures: that was several weeks of iteration, no weekend installation. The policy documentation especially surprised us. The AI can only know what is written down somewhere.

It needs ongoing upkeep. Every month we spot-check classifications and drafts. New products, new promotions, new questions: without upkeep, every AI sorting slowly gets worse.

Who this pays off for

From roughly 100 requests a week, the build pays for itself quickly. Below that I would work with a good template library first and add the AI later. And if your actual problem is the sheer volume of status questions, start there: the guide to automating customer service shows the whole map.

Conclusion

Pre-sort first, reply fully automatically never: that is the core of our setup at nano. The AI takes over reading, classifying and the first draft. The human keeps the decision. The three failures showed us why this exact order is the right one. Each of them would have landed at a customer as a fully automatic reply.

If you want a setup like this for your store, or first want to know whether it pays off at your volume: write to us at Flowhouse. We are happy to show you how it works at nano in detail.