The job is not to answer the mail
Workflow 02.01 has a narrow job. It watches Gmail, reads a new message, applies a label, records the decision and interrupts the owner only when the message needs a person today. It never replies. It never archives. It never deletes. That boundary matters because classification is a useful model task, but it is still a judgement made from incomplete text.
The trigger ignores chats and messages already carrying the Newsletter label. It also limits the query to recent mail. The next step keeps the sender, subject, date and the first 2,000 characters of the plain-text body. It replaces repeated whitespace, but it does not recognise signatures or quoted history. This caps the input, but it creates the first trade-off: a decisive sentence near the end of a long thread may be cut off.
Six labels, each with a different meaning
The classifier may return only these categories:
- Lead: a prospective customer asking about work, availability or fit.
- Client: a message from or about an existing customer relationship.
- Invoice: a bill, payment request or overdue-payment message.
- Supplier: a vendor or partner message that belongs to the operating side of the business.
- Newsletter: marketing or editorial mail sent to a list.
- Noise: automated no-reply mail and messages that need no useful action.
Those classes are deliberately ordinary. They match labels a small service business can scan in Gmail. The model also returns an urgency of today, this_week or whenever, a short summary, and a needsHuman value. The prompt says that needsHuman is true only when somebody must decide or reply personally.
The interrupt rule is smaller than the classification rule
Every classified message receives its Gmail label and a row in the Inbox Triage sheet. A Slack message is different. It is sent only when both conditions are true: the model marked the message as needing a human, and its urgency is today.
That distinction prevents the alert channel from becoming a second inbox. A supplier newsletter can be labelled Supplier or Newsletter without interrupting anyone. A client update due later can remain visible in Gmail and in the sheet without producing a Slack ping. The notification is not a verdict that the other mail does not matter. It is a request to look now.
A real enquiry can still be classified as noise
Consider this subject: “Quick question about next month.” The body begins with a generic introduction, contains a long quoted thread, and ends with a request for availability. If the request falls outside the shortened body, the model may see only generic text. It could return Noise with needsHuman set to false.
The workflow then applies the Noise label and logs the decision. It does not send Slack. Crucially, it also does not remove the message from Gmail. The failure is a missed interruption, not a destroyed enquiry. The owner can find the original message, and the sheet keeps the sender, subject, category, urgency and summary needed to inspect the decision.
That is the recoverable failure mode. It is not a complete safety system. If nobody reviews the Noise label or the log, the enquiry can still sit unnoticed. A sensible operating rule is to scan newly labelled Noise and Newsletter mail during the first weeks, then keep a regular spot check after the categories settle. When the same mistake repeats, change the prompt or extraction rule instead of correcting labels forever.
Where rules should beat the model
Some signals are too clear to spend judgement on. A known client domain, a billing mailbox or a form with a fixed subject can be routed by a rule before the model runs. The model is better used for ambiguous mail: a new sender, a vague subject, or a message whose intent sits in the prose.
The current workflow does not contain a sender allowlist or a confidence threshold. Adding either can make a specific business safer, but pretending they already exist would hide the real design. As shipped, the safeguard is modest: constrained output, no automatic reply, no deletion, and a log that makes mistakes inspectable.
Where this workflow does not fit
If a mailbox carries emergency requests, legal deadlines or orders whose loss causes immediate harm, model-first triage is the wrong front door. Deterministic rules and a monitored queue should catch those messages before any classifier. A help-desk system may also be better when several people need ownership, status and escalation rather than labels in one Gmail account.
There is another limit. The workflow has been checked against a real n8n installation, but not run end to end with real Gmail, OpenAI, Slack and Google Sheets accounts. Credential behaviour, label identifiers and live message formats still need a test account before activation. The first run belongs in a mailbox made for testing, not in the owner's working inbox.
The design test
The useful question is not whether the model always chooses the right label. It will not. The useful question is what one wrong label can do.
Here, the answer is bounded. A mistake can suppress an alert and put a message under the wrong label. It cannot answer the sender, delete the mail or make the source disappear. The log provides a place to see the pattern and improve it. That is enough to make classification useful without pretending it is certainty.