Skip to content
namiciLabby pentry

n8n - Gmail Lead Triage

Thirty to fifty emails a day, and the three that matter are buried. This sorts them in Gmail, using Gmail labels - and it is deliberately careful about what it is allowed to move out of your sight.

US$4.99

  • n8n
  • Gmail
  • Email automation
  • AI classification
n8n-Gmail-Lead-Triage

You get somewhere between thirty and fifty emails a day. Client enquiries, vendor pitches, newsletters you never subscribed to, and the usual scattering of one-off questions. Three of them matter.

The expensive part is not the time spent scrolling. It is the enquiry that gets buried and found four days later, by which point the person has hired somebody else. That happens quietly, it happens more than once, and you rarely find out it happened at all.

This is an n8n workflow that sorts your inbox with AI. It runs in Gmail, using Gmail labels, so nothing moves into a separate system you have to remember to check. And it is built around one rule that most inbox filters get wrong.

Why accuracy is the wrong thing to optimise

A classifier that is 95% accurate sounds excellent. On fifty emails a day that is two or three mistakes, which feels like a rounding error.

But those mistakes are not interchangeable, because the two ways of being wrong cost wildly different amounts.

  • A newsletter left in your inbox costs about two seconds. You see it, you ignore it, you move on. You may not even register that a mistake happened.
  • A lead moved out of your inbox costs you a client. And you never find out, because not seeing it is the entire nature of the mistake.

An accuracy score treats those as the same event. They are not remotely the same event. One is a shrug. The other is the precise failure you were trying to prevent, now happening silently and with more confidence than before.

A filter that buries one real enquiry a month has made your situation worse, however good its accuracy score looks.

So the rule is deliberately lopsided

Hiding an email requires high confidence. Surfacing one does not.

In practice that is two separate numbers, both of which you can change. Acting on something - starring it, flagging it, pushing it up the pile - needs a confidence of 0.6. Moving something out of your inbox needs 0.85. Anything that falls between them, or below both, keeps its place in the inbox and gets an "unsure" label instead.

The consequence is that on an ambiguous day your inbox ends up slightly busier rather than slightly emptier. That is the correct direction to fail in. A filter that occasionally shows you something you did not need is doing its job badly. A filter that occasionally hides something you did need is not doing its job at all.

None of that works if the confidence score is decorative, and by default it usually is - ask a model how certain it is and it will say ninety percent about nearly everything, because sounding confident is what its training rewarded. The instructions in this workflow push back on that explicitly, telling it that a low score is never punished but a wrongly confident one hides real work. That single sentence is what turns the threshold into a real control.

What actually happens to each email

Every few minutes the workflow asks Gmail what has arrived that it has not already handled. Each of those messages goes through the same short pipeline.

  • A rule runs first. Senders like noreply, newsletter, mailer, marketing and campaign are labelled and moved out of the inbox immediately, with no AI call at all.
  • Everything else is classified as a lead, a real question, a vendor pitch or bulk mail - with a separate urgency rating, a confidence score, and a one-line reason.
  • The thresholds are applied in code, not by the model, along with your protected-sender list.
  • Then it acts. Leads are starred, marked important and labelled. Urgent mail is starred. Questions are labelled and left alone. Bulk mail is labelled and moved out of your inbox. Anything uncertain is labelled unsure and left exactly where it was.

The reason is stored with every email, so when the classifier gets one wrong you can see why rather than guessing. After a week that tells you far more about where your thresholds should sit than any accuracy figure would.

A rule before the model, on purpose

The prefilter exists because it is cheaper, but cost is not the real reason. It is more reliable. A pattern matching "noreply@" gives the same answer every single time. A language model gives the same answer almost every time, and the gap between those two is where the surprises live.

Use judgement only where judgement is actually needed. Most of what clogs an inbox does not need any.

Senders that can never be archived

There is a list of protected domains that the workflow will not move out of your inbox whatever the AI decides. Existing clients, your accountant, the people you genuinely cannot afford to miss.

That list is checked before the bulk rule as well as after the classifier - which matters more than it sounds. A website contact form usually emails you from something like noreply@yourdomain.com, and without that protection the fast rule would archive your own enquiries as junk. Put your own domain on the list and form notifications are safe from both paths.

Nothing left behind

Most inbox automations poll using a stored timestamp: what has arrived since I last looked? That works until it does not. If the automation is off for an hour, or the server restarts, or somebody toggles it, the timestamp can move without the mail in that window ever being processed. Every run afterwards reports success, and the skipped emails leave no trace anywhere.

This one does not remember anything. Every few minutes it asks a different question: what has arrived in the last two days that does not already carry a "processed" label? Each email gets that label as its final step, after it has actually been sorted.

Downtime, a restart, an email you read on your phone before the sweep ran - all of them are simply found on the next pass, because the workflow checks the world rather than trusting its own memory of it. And because the label is applied last, a failure anywhere upstream leaves the email unprocessed so it is retried, rather than marked done and quietly skipped.

When something breaks

If the model times out or returns something unusable, the email is labelled for review and left exactly where it was. Nothing is ever hidden by an error.

That sounds obvious written down, and it is not what happens by default. The default is that a failed step ends the run, the email is never touched, and it sits in your inbox indistinguishable from mail the system deliberately left there - so you cannot tell "this was checked and it is fine" from "this was never looked at".

The Telegram ping, if you want it

Leads and genuinely urgent mail can send a short Telegram message: the sender, the subject, the model's one-line reason and a direct link to the thread. Enough to decide whether to stop what you are doing, without opening your inbox to find out.

Only those two categories trigger it. Notifying on everything would just rebuild your inbox somewhere noisier, which is the problem rather than the fix. It is entirely optional - leave the node switched off and everything else works the same.

What you need

  • An n8n instance, cloud or self-hosted
  • A Google account, connected through n8n's Gmail credential
  • An OpenAI API key. It runs on a small model - at fifty emails a day, expect cents per month
  • Telegram, only if you want the hot-lead alerts

No database. No Supabase, no SQL, no vector store. State lives in Gmail labels, which is unusual for a workflow like this and is why setup is one sitting rather than one weekend.

What it does not do

It does not write replies. It does not delete anything. It does not give you a dashboard, and it does not move your mail into a system you have to remember to open.

Archived mail stays in All Mail and stays searchable - nothing is destroyed, and every decision it makes is one click to undo.

Setting it up, honestly

About twenty minutes, and the Gmail connection is the only fiddly part. The download walks through it step by step, including the detail almost every guide leaves out: a Google OAuth app left in "testing" mode expires its tokens after seven days, so your connection works perfectly and then breaks a week later for no visible reason.

After that you run a small installer branch that creates the six Gmail labels, pick those labels in the nodes that use them, and set your thresholds and protected domains in a single config node.

For the first run the guide asks you to process three emails rather than fifty, and to switch off the two nodes that archive. Everything still gets classified, starred and labelled - but nothing leaves your inbox. You click the Bulk label to see exactly what it would have archived, and only turn those nodes on once you are happy. That is the whole test, and it costs you nothing.

What is in the download

  • The workflow, as an n8n JSON file with no credentials in it
  • A step-by-step guide to connecting Gmail, with the seven-day token trap explained
  • A guide to creating the labels and wiring them to the right nodes
  • The search query explained in full, with sensible variations for different mailboxes
  • Sticky notes on the canvas explaining what every branch does and why it exists

It is written to be read and changed, not treated as a black box. If you want different categories, a different urgency rule, or an extra branch that pushes leads into a CRM, everything you need to do that is on the canvas.

Questions

Will it delete anything? No. It adds labels, stars mail, and removes the inbox label from bulk - which is what archiving is in Gmail. Everything stays in All Mail and stays searchable.

What if it gets one wrong? Move it back, and adjust the thresholds in the config node. The reason the classifier gave is stored on every email, so you can see what it was thinking rather than guessing.

Will it work on a mailbox that is not Gmail? Not as shipped. It uses Gmail labels and Gmail search, which have no direct equivalent in Outlook or IMAP.

How much does the AI cost? At fifty emails a day on a small model, a few cents a month. The rule-based prefilter removes most bulk mail before any call is made.

What happens to my existing backlog? Nothing, by default - it looks at the last two days. The guide shows how to widen that for a one-time catch-up if you want it.

Does it read my email? It reads the sender, subject and preview of each message to classify it. Nothing is stored anywhere outside Gmail, and nothing is sent anywhere except the model call that does the classification.

Get it

Gmail Lead Triage — $ 4.99

One n8n workflow, the setup guides, and the canvas notes. If you would rather have it adapted to your setup - your own categories, a different mailbox, leads pushed into a CRM - that is the work I do, and you can tell me what you need.

Got an Idea?

Let's shape it into something people love to use.