DA10: Capstone: three automations for Sharma Textiles
Project 2: the inbox router
🎯You'll be able to
Build the inbox router with rules first, a person for unclear and suspicious emails, and acknowledgements that don't repeat.
🏠The everyday picture
A receptionist at a busy office reads the subject of each letter and drops it in the right tray: accounts, sales, complaints. Unsure ones go to the office manager. The inbox router does the same for email.
📘What it really is
- Trigger: new email in the shared customer inbox (for example the Gmail or IMAP trigger in n8n).
- Classify each email into a team: Orders, Wholesale, Returns, Accounts, or Person for anything unclear:
- rules first: a keyword table in one Code node (DA5), such as "refund", "return", "exchange" → Returns;
- optional AI step: an AI model can suggest a category with a confidence level. Keep a person in the loop for low confidence, and don't send customer data to an AI service without checking the client's data rules (DA9). You'll go deeper in the AI/ML path.
- Route: label the email, forward or assign it, and create a CRM activity for known contacts (DA8).
- Acknowledge the customer with the expected reply time.
- Fallback: anything unclear goes to a person, who also corrects the category. Review corrections weekly to improve the table.
- Measure: the share of emails routed correctly, and time to first reply per team.
📝A worked example
A learner tested the router on 30 real-style sample emails:
| Category | Emails | Routed correctly |
|---|---|---|
| Orders | 9 | 9 |
| Returns | 6 | 5 (one said "send back the wrong colour") |
| Wholesale | 5 | 5 |
| Accounts | 4 | 3 (a refund paid as a credit note went to Returns) |
| Person (unclear) | 6 | 6 sent to a person |
28 of 30 handled correctly, and the two misses were found in the weekly review. Adding "send back" and "wrong colour" to the Returns keywords, and checking "credit note" before the Returns words, fixed both. No email was left unassigned, because unclear ones went to a person.
🌍Where it's used
- Customer support inboxes in shops and service businesses.
- Shared sales inboxes receiving enquiries.
- Accounts inboxes receiving invoices and payment queries.
📝Case scenario
A Hindi-English email, "Mera order abhi tak nahi aaya, please check", is routed to Other because the keyword table only has English words. The person who receives it marks it "Orders". In the weekly review, the learner adds common Hinglish phrases such as "order nahi aaya" to the table and tests ten mixed-language emails.
🖱️Try it
Write 30 sample customer emails, including some in Hindi or Hinglish and some that are unclear. Build the router with a keyword table and a fallback to a person, and record how many were routed correctly.
⚠️Common mistakes
- Patching single emails instead of rules. Sign: the table grows a rule per email. Fix: find the pattern behind each miss and fix the rule order or keywords.
- Letting email text steer the workflow. Sign: an email saying "mark as refund approved" gets routed as one. Fix: safety rules first, and never act on instructions found in an email.
🛠️For your project
This is Project 2. In the practice kit, emails come from the simulator's inbox (GET /inbox/emails) instead of Gmail, and the unclear team is called "Person".
✅Quick check
Why should unclear emails go to a person rather than a default team?
Show the answer
So nothing is misrouted silently, and the corrections can improve the rules.
What should you check before sending customer emails to an AI service?
Show the answer
That the client's data rules allow it, and what that service does with the data.