To sort emails with AI, connect the inbox to a system that understands the request, assigns a category, and routes it to the right person. Also define what happens when the message doesn’t fit, contains several topics, or belongs to a conversation someone is already handling.
What you want is simple: open the inbox and know what each message needs, who owns it, and what’s still pending. A label helps you find it; assignment and status let you work on it without two people replying at once or both assuming the other will do it.
When filters are enough and when AI helps
If messages follow a stable pattern, start with rules. A notice that always comes from the same address or includes a fixed reference in the subject can be routed to its label without interpreting the text. Gmail filters let you apply actions to messages that match search criteria.
AI is useful when different phrases express the same need. “I want to expand the service,” “we need to cover another office,” and “can we add this option?” could all be sales enquiries even if they don’t contain the word “quote.” You need to test that with representative messages from your business.
It also matters to recognise what the person is ruling out: “I don’t need another quote, I need you to fix the issue” shouldn’t go to sales just because it contains a certain word. You can combine rules for the clear-cut cases and content-based classification for messages that need interpretation.
Design categories that lead to the next step
Choose categories that change who handles the message or what work needs to be done. This could be a sample starting point for a general inbox:
| Category | What to do with the message |
|---|---|
| Sales enquiry | Assign information or expansion requests to whoever handles new opportunities. |
| Service issue | Open or update a support ticket for problems with an active service. |
| Administrative documents | Pass documents that need to be logged or reviewed to the responsible team. |
| Review | Check ambiguous or incomplete messages and decide where they should go. |
Pair each category with examples and exclusions. An email with an invoice attached may fall under administrative documents; one questioning an amount needs a review of the enquiry. The attachment alone does not determine what work needs to be done.
Keep topic and status separate. “Issue” says what it’s about; “pending assignment,” “in progress,” or “resolved” says where it stands. Applying a label should not automatically mark the request as handled.
Connect message arrival to a visible task
The flow can start simply:
- Detect the new message. Log the inbox, the message, and its source conversation.
- Prepare the content. Separate the current request from signatures and quoted text when possible, while keeping the original.
- Classify. Apply the agreed rules or suggest a category from the text.
- Assign. Create or update the matching task, with owner and email link.
- Record the outcome. Distinguish between assigned, pending review, and processing failures.
Use a stable reference to recognise a message that has already been processed. If a connection retries the same operation, it shouldn’t create another identical task. A new reply, on the other hand, may require updating the existing task.
Decide how much context the classifier needs. A “yes, go ahead” doesn’t make sense on its own; it may need the previous message. Nor is it a good idea to carry an old category across the whole conversation: the client may bring up something else. The owner should be able to correct the destination and keep that decision.
If the message contains documents that need their own handling, connect that stage separately. For example, automating invoices received by email includes document extraction and validation, in addition to the initial routing.
Leave a destination for what doesn’t fit
The routing needs a review path and someone to handle it. Also define how a message with more than one request will be handled: multiple labels, linked tasks, or a main owner who coordinates the reply.
The n8n text classifier documentation shows options for allowing multiple categories and deciding what to do if there is no clear match. In that last case, its default option removes the item from the node output; it also allows sending it to an “Other” branch. It’s a good idea to connect that output to a review step. Dropping the item at that stage doesn’t mean deleting the email from the inbox, but it may leave it without the follow-up you expected.
A technical failure needs different treatment: if reading the email or connecting to the model fails, it should be logged as pending processing. Don’t confuse that with a valid category or with a message that doesn’t need attention.
Example: one email asks for an expansion and reports a failure
Imagine this message in a service company:
We want to expand the service to another office. Also, since yesterday we haven’t been able to access the client area. Could you check it?
It’s an illustrative example. The expected routing could create a sales enquiry and link an issue to the same email. The team decides who coordinates the reply so the client doesn’t have to explain everything again.
If the setup only allows one category, the message should go to the person who reviews mixed requests or follow an agreed priority rule. Choosing only “sales” would leave the access issue unresolved.
When the client’s reply arrives, keep the link with the message and the previous tasks. And if someone corrects the assignment, avoid letting the next run impose the original destination again without checking that correction.
Test the real inbox before scaling the routing
Gather an authorised sample of messages with categories reviewed by the team. Include short replies, long threads, forwards, mixed requests, and messages without enough information. Also check what the system receives when there are attachments: reading the email body is not the same as reading the files.
Start by suggesting labels and owners so the team can compare them. Log corrections by category and requests that were left unassigned. Measure the time it takes until someone takes the request, including the work of reviewing doubtful cases.
New email and historical email may need different flows. Microsoft notes in its email troubleshooting guide for Power Automate that moving a message between folders does not trigger the flow described for new email arrival. If you want to classify old messages, plan a specific run and check that it doesn’t reopen already resolved issues.
Before scaling the system, test a disconnect and a retry. The team should be able to locate pending messages and keep working from the inbox. After that, review the categories when services, owners, or customer support processes change.
At Digency, we build custom automations to connect email with business tasks. Tell us what reaches your inbox and who should handle it: we’ll define an initial routing you can test with your team.
Header image: AI-generated illustration.
