n8n 電郵分流工作流運行 60 天，作者總結三項失誤教訓

The Inbox Autopilot: What 60 Days of Letting an n8n Workflow Triage My Email Taught Me

This is part of my build-in-public series on running LLM workflows in n8n in production. Everything here is from a real template I sell and support — the mistakes are mine, the fixes are tested.

The 45 minutes nobody budgets for

Every morning I did the same thing: open Gmail, scan 60–80 new emails, decide what needed a reply, what could wait, and what was noise. It took 45 minutes on a good day. Not writing replies — just deciding. The triage, not the work.

So I built a workflow to do the deciding. A Gmail trigger, a classifier, a draft-reply generator, and a morning review. It's been running for 60 days. It now saves me about 35 minutes every morning. But the interesting part isn't the time saved — it's the three ways it failed, each of which taught me a rule I now apply to every classifier I build.

The architecture (one paragraph)

Gmail Trigger on new mail → a Code node that strips signatures, disclaimers, and quoted history → a classifier LLM call that assigns one of five buckets: urgent, needs-reply, waiting-on-me, newsletter, noise → a confidence gate → for needs-reply, a second LLM call drafts a reply in my voice → drafts land in Gmail as drafts, never sent. Urgent gets a Slack/Telegram ping. Newsletters get auto-archived. The morning review is a Gmail search: in:draft newer_than:1d, five minutes, approve or edit.

The one hard rule: the workflow never sends email. Draft-only. That single constraint makes every other failure recoverable.

Failure #1: the confident misclassification

Week two, a customer wrote in with a refund request. Long email, polite tone, order number buried in paragraph three. The classifier filed it as newsletter with 0.91 confidence.

Why? My few-shot examples were synthetic — tidy little emails I wrote myself, each fitting its bucket perfectly. Real email is not tidy. The model learned "polite + long = newsletter" from my examples and confidently applied it.

The fix was to throw away the synthetic examples and few-shot with my real email — 40 actual messages, warts and all, including the ones where a refund request reads like a thank-you note. Accuracy on the tricky cases went from "scary" to "boring." Synthetic examples teach the model a clean world that doesn't exist.

Failure #2: the tone-deaf draft

Classification fixed, drafting began. The first week of drafts were grammatically fine and emotionally wrong. An annoyed customer got a cheerful "Happy to help! 🎉" reply. A formal partner email got slang.

The problem: one system prompt for all drafts. The fix: per-bucket tone templates. The drafting prompt receives the bucket and a one-line voice card: needs-reply-angry → "acknowledge the frustration first, no exclamation marks, no emojis, state what happens next"; needs-reply-formal → "use their name, sign with full signature." It's not fancy, but misfire rate on tone dropped to near zero. Voice is a parameter, not a personality.

Failure #3: thread blindness

This one cost me a customer interaction. Someone replied to an existing thread; the workflow classified the single message — "Sounds good, let's do it" — as noise. It was a purchase confirmation for a $79 custom service request. The purchase-confirmation context lived three messages up, which I'd stripped as "quoted history" to save tokens.

Lesson: strip quoted history for classification, but fetch the thread for context when it matters. Now the classifier gets the current message plus the last two messages of the thread (compressed), which costs ~300 extra tokens and catches every "sounds good" that actually means something. Token savings that break decisions aren't savings.

The confidence gate (the part I'd copy anywhere)

Every classification returns a confidence score. Below 0.75, the email goes into a sixth bucket: unsure — always shown to the human, never auto-filed. The unsure bucket gets 10–15% of mail, and that's by design: it's where the classifier admits ignorance instead of being confidently wrong. I'd rather review 12 emails than un-archive one misfiled refund.

This is the same pattern as the review-queue and retry-budget posts in this series: the system's honesty about its own limits is the feature. A classifier without an unsure bucket is a liar with good PR.

The cost math

~70 emails/day, classification at ~600 tokens each plus drafts for ~10 of them: about $0.40/day on GPT-4o-mini. The 35 minutes it saves me every morning would need to be worth $0.40. It is. The Gmail API is free, n8n is self-hosted, and the only real cost was the week I spent fixing the three failures above.

What I kept manual

Two things deliberately stay human: the final send (I read every draft before it goes — the 5-minute morning review is the whole quality system), and the unsure bucket (which is a human inbox by another name). Everything else — reading, sorting, drafting, archiving — is the workflow's. That split has held for 60 days without an incident worth mentioning, which for an email automation is the highest praise I have.

I'm building AI Automation Lab — production-ready n8n workflow templates. The AI Inbox Triage & Reply Drafter is the full workflow from this article: the Gmail trigger, the classifier with real-email few-shots, the confidence gate, the per-bucket draft templates, and the morning-review setup. My open-source patterns live at github.com/zhp910318/n8n-ai-automation-lab.