How to Automatically Tag and Route Incoming Emails with AI

The inbox problem

Most teams have at least one shared email address. A support alias, a sales inbox, an info@ catch-all. These inboxes work fine when volume is low. They break the moment traffic picks up, because the problem isn't receiving email - it's deciding what to do with it.

The standard solution is keyword rules. If the subject contains "invoice", forward to billing. If it contains "bug" or "error", create a support ticket. Rules are easy to write and they work until they don't. Someone writes "I was charged twice" and the billing rule misses it entirely. Someone sends a general question with the word "problem" in the subject and gets routed to engineering.

AI classification solves this at the intent level. Instead of pattern matching on keywords, you're matching on what the sender actually means. The same routing accuracy you'd get from a human reader, running in under 300ms, at any volume.

Designing your routing categories

Your category list is what determines where each email ends up. Design it around your team structure and the actions you actually want to take, not around what you think people might write.

A practical starting set for a SaaS company's info@ or support@ inbox:

• billing_and_payments - invoices, charges, refund requests, subscription changes
• technical_support - bugs, errors, product not working as expected
• sales_inquiry - pricing questions, demo requests, partnership interest
• onboarding_help - setup questions, getting started, integration guidance
• feature_request - suggestions, missing functionality, roadmap questions
• account_access - login problems, password resets, team member invites
• general_question - anything that doesn't fit the above
• needs_review - low-confidence results that should be reviewed by a human

Resist the urge to create too many categories upfront. Eight well-defined buckets that have clear owners are more useful than twenty overlapping ones.

A real classification request

An email arrives at your support alias:

Subject: Re: getting started
Body: Hey, I signed up yesterday and I'm trying to connect your
API to our internal dashboard. I found the docs but I'm stuck on
the authentication step - my requests keep returning 401 even
though I copied the key exactly from the settings page.

You pass the subject and body to classifaily:

curl -X POST https://api.classifaily.com/v1/classify \
  -H "Authorization: Bearer cai_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "input": "Subject: Re: getting started\n\nHey, I signed up yesterday and I'\''m trying to connect your API to our internal dashboard. I found the docs but I'\''m stuck on the authentication step - my requests keep returning 401 even though I copied the key exactly from the settings page.",
    "categories": ["billing_and_payments", "technical_support", "sales_inquiry", "onboarding_help", "feature_request", "account_access", "general_question", "needs_review"],
    "explain": true
  }'

Response:

{
  "label": "onboarding_help",
  "confidence": 0.91,
  "reasoning": "New user (signed up yesterday) attempting initial API integration, experiencing authentication failure during setup. The issue is setup friction rather than a broken product - consistent with onboarding_help rather than technical_support.",
  "request_id": "req_02pm..."
}

Route this to your onboarding or developer success queue, not the general support queue. The distinction matters: an onboarding rep can resolve this faster than a tier-1 support agent because they know the common setup pitfalls and have the right context.

Connecting to your email pipeline

How you integrate depends on your email stack. Three common patterns:

Webhook-based (most flexible): If your email provider supports inbound webhooks - Postmark, SendGrid Inbound Parse, Mailgun Routes - you can receive each incoming email as a POST request, classify it in your handler, and act on the result immediately. This is the lowest latency option and keeps everything in your own code.

Automation tools (no-code): Gmail and Outlook both work with Zapier, Make, or n8n. A trigger fires on each new email, a classifaily step classifies it, and downstream steps apply labels, move it to a folder, create a ticket in your helpdesk, or send a Slack notification. No infrastructure required.

Scheduled polling (simplest to start): If you're just prototyping, a cron job that checks the inbox every few minutes, classifies unread messages, and applies labels is enough to test your category design before building anything more robust.

Handling multi-topic emails

Some emails cover more than one subject. A user writes about a billing question in the first paragraph and then mentions a bug in the second. A single label won't cover both.

Two approaches work well here. The first is to classify the primary intent - most emails have one main reason for being sent even if they include secondary topics. A needs_review fallback category catches ambiguous cases for human triage.

The second is to split the email at the paragraph level and classify each segment independently. Use the batch endpoint to send multiple segments in one request:

curl -X POST https://api.classifaily.com/v1/batch \
  -H "Authorization: Bearer cai_live_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "items": [
      { "id": "seg_1", "input": "I need to update my billing address before the next invoice." },
      { "id": "seg_2", "input": "Also, the export button on the reports page throws an error." }
    ],
    "categories": ["billing_and_payments", "technical_support", "sales_inquiry", "onboarding_help", "feature_request", "account_access", "general_question"]
  }'

This gives you a label per segment and lets you take multiple actions from a single email - forward the billing segment to finance and open a bug ticket for the export issue - without asking the sender to split their message.

Setting a confidence threshold

Not every email will classify cleanly. A cryptic one-liner or a message in an unexpected language may return a low confidence score. You should handle these explicitly rather than routing them blindly.

A practical threshold pattern:

• Confidence ≥ 0.85: Route automatically, no human review
• Confidence 0.65 – 0.84: Route to the predicted category but flag for a spot-check
• Confidence < 0.65: Place in a general review queue for manual triage

Start with conservative thresholds and loosen them as you confirm the model is routing accurately for your specific email patterns. A month of data will tell you where the edge cases actually live.

Measuring routing accuracy

Build a lightweight feedback loop from the start. When a team member reassigns a routed email to a different queue, log the original classification label and the corrected one. This gives you a misrouting rate you can track over time.

Misrouting patterns often reveal category design problems, not model problems. If account_access keeps getting confused with technical_support, the category descriptions or your label definitions may be too similar. Tighten the distinction in your category list and the accuracy typically improves without any other changes.

Getting started

The free plan includes 100 classification requests per month - enough to run a week of real inbox traffic through the API and evaluate how well your category design works before building any automation. Start with a manual prototype: export a sample of past emails, classify them in bulk using the batch endpoint, and check whether the labels match where you would have routed them.

The full API reference is in the API documentation.