KoltrixClassifying inbound mail by intent: a starter taxonomy
A ready-to-use set of intent categories for a SaaS inbox, with definitions, example emails and routing for each, plus rules for keeping the list short.
On this page(6 sections)
- Intent is different from category
- The starter taxonomy
- 1. Question
- 2. Bug
- 3. Billing
- 4. Cancel
- 5. Feature request
- 6. Sales lead
- 7. Partnership
- 8. Legal or security
- 9. Spam or irrelevant
- The routing table
- Rules for keeping the taxonomy useful
- Keep it under ten
- Write definitions, not just names
- Allow exactly one primary intent
- Handle "other" honestly
- Review quarterly
- Using the taxonomy with AI classification
- Key takeaways
"What kind of email is this?" is the question behind every triage decision, and most teams answer it differently every time. An intent taxonomy is just a shared, written answer: a short list of reasons people write to you, with clear definitions and a routing rule for each.
Whether you sort by hand, with rules or with an AI classifier, the taxonomy is the same. Below is a starter set for a typical SaaS inbox that you can copy and adapt.
Intent is different from category
Many inboxes already sort mail by type: primary conversations, newsletters, automated updates, cold pitches. That answers "should a human look at this soon?"
Intent answers a different question: "now that a human is looking, what does this person want?" A customer email in your main view could be a bug report, a billing question or a cancellation, and each one needs different handling. Both layers are useful, and they work well together.
The starter taxonomy
Nine intents cover most of what a SaaS company receives. Use them as labels, as categories in your helpdesk, or as the output list for an AI classifier.
1. Question
Definition: The sender wants to know how to do something, or whether the product can do something. Example: "Is there a way to export only last month's data?" Route to: Frontline support. Link docs where possible; update docs when the answer isn't there.
2. Bug
Definition: Something isn't working as expected or documented. Example: "The export button does nothing since this morning." Route to: Frontline support to gather details and reproduce, then engineering with a structured ticket.
3. Billing
Definition: Invoices, charges, payment methods, receipts, tax details, plan pricing for existing customers. Example: "We were charged twice this month." Route to: Whoever handles billing, with clear authority on refunds.
4. Cancel
Definition: The sender wants to cancel, downgrade, or is clearly considering it. Example: "How do I close our account?" or "We're not getting value from this anymore." Route to: Support, with a fast and respectful path. Optionally flag to whoever owns retention, but never make cancelling hard.
5. Feature request
Definition: The sender wants the product to do something it doesn't currently do. Example: "It would be great if reports could be scheduled weekly." Route to: Support replies honestly, then logs the request (with the customer's words) wherever product feedback is tracked.
6. Sales lead
Definition: A prospect interested in buying, or an existing customer interested in expanding. Example: "We're a team of forty; what would pricing look like?" Route to: Whoever handles sales. Reply quickly; leads cool fast.
7. Partnership
Definition: Integrations, co-marketing, reselling, affiliate or agency proposals from someone who isn't trying to sell you a service. Example: "We'd love to build an integration between our tools." Route to: A founder or whoever owns partnerships. Distinguish genuine proposals from disguised sales pitches.
8. Legal or security
Definition: Vulnerability reports, data requests, legal notices, compliance questionnaires, account-access or ownership disputes. Example: "I found a way to view other users' invoices." or "Please delete all data you hold about me." Route to: A named owner immediately. These should never sit in a general queue.
9. Spam or irrelevant
Definition: Unsolicited pitches, SEO offers, scams, misdirected mail. Example: "We can get your site to the first page of search results." Route to: Archive or delete. No reply needed in most cases.
The routing table
Put the whole taxonomy on one page so anyone can apply it.
| Intent | Owner | Response target | Notes |
|---|---|---|---|
| Question | Frontline | Standard | Link or create docs |
| Bug | Frontline, then engineering | Standard, faster if blocking | Use the bug ticket template |
| Billing | Billing owner | Standard | Refund authority defined |
| Cancel | Frontline | Fast | Never obstruct |
| Feature request | Frontline | Standard | Log with customer's words |
| Sales lead | Sales owner | Fast | Same business day if possible |
| Partnership | Founder / partnerships | Within a few days | Filter out disguised pitches |
| Legal or security | Named owner | Immediate | Never in a general queue |
| Spam | Nobody | None | Archive or delete |
Rules for keeping the taxonomy useful
Keep it under ten
Every additional intent creates new borderlines where people (and classifiers) disagree. If you can't decide between two intents for a typical email in under five seconds, merge them or rewrite the definitions.
Write definitions, not just names
"Billing" means different things to different people. One sentence of definition and one real example per intent prevents most disagreements.
Allow exactly one primary intent
Emails often contain several requests: "The export is broken, and also, can we add two seats?" Pick the intent that drives the most urgent action (here, Bug), handle the rest in the reply, and add a secondary label if you track that.
Handle "other" honestly
Some mail won't fit. Rather than adding categories, let it fall into the closest intent or a temporary "unsure" label, and review those weekly. If a pattern emerges, that's when you add or redefine an intent.
Review quarterly
Look at a sample of recent mail per intent. Are definitions still clear? Is one intent swallowing too much? Did a new kind of email appear?
Using the taxonomy with AI classification
An AI classifier needs exactly what a new teammate needs: a short list, clear definitions and examples. If you're configuring a model or prompt to classify intent, give it the definitions above verbatim, include one or two example emails per intent, and tell it to pick a single primary intent. Then check its output on a sample of real mail before relying on it, paying special attention to Legal or security, where a missed email is costly.
Key takeaways
- Intent (what the sender wants) complements category (how urgently a human should look).
- Nine intents cover most SaaS inbound mail: question, bug, billing, cancel, feature request, sales lead, partnership, legal or security, spam.
- Every intent needs a definition, an example, an owner and a response target.
- Keep the list under ten, choose one primary intent per email, and review quarterly.
Start with Koltrix
Your domain, one inbox, and an API that sends.
A team inbox where AI sorts and drafts (nothing is sent without your click), plus the transactional API and SMTP relay your product sends with. 7 days free, no card.
