Inbox Triage Automation: A Build Breakdown

Most inbox automation pitches skip the part that matters: where the system should stop being clever and hand the thread back to a human. That handoff is the whole job. Get it wrong and you ship faster replies that quietly torch customer trust. Get it right and you save your team five to fifteen hours a week without anyone outside the company noticing the difference.

Here's how a Catalyst inbox triage build actually comes together — the steps, the decision points, and the honest tradeoffs you sign up for.

Step 1: Secure inbox connection (and why this takes longer than you'd think)

The first hour of every build is plumbing. We connect to your mail provider — Gmail Workspace or Microsoft 365 in almost every case — using OAuth with scoped permissions. No passwords stored, no IMAP credentials floating in a config file, no shared service accounts. The automation gets read and modify access to a specific mailbox (usually a shared inbox like support@ or sales@), and that's it.

This step is boring and it's also where most DIY builds quietly become a security problem. A few things we insist on:

• The connection is scoped to one mailbox, not the whole domain.
• Tokens are stored encrypted and rotated on a schedule.
• Every action the automation takes is logged with a timestamp and the message ID, so you can audit exactly what happened to any thread.

If you're in a regulated space — health, legal, financial advice — this step gets longer because we add a data processing review before any message content leaves your environment. Budget an extra week if that's you.

Step 2: Classification — the model does less than you think

The core of the system is a classifier that reads each new message and assigns it to a category. For most small businesses, four buckets cover 90% of volume:

• Sales — prospect inquiries, pricing questions, demo requests
• Support — existing customers with questions or problems
• Spam / cold outreach — vendor pitches, SEO spam, recruiter blasts
• Other — internal, personal, partnership, anything that needs a human to read it cold

We use a language model for this, but the prompt is tight and the categories are yours, not ours. During the build we sit down with you and look at 200-500 historical emails together. You tell us which bucket each one belongs in, and we calibrate the prompt against your actual mail, not a generic template. This is the single highest-leverage hour of the project.

A few honest notes on classification accuracy:

• Expect 92-97% accuracy on clear cases after calibration.
• Edge cases — a current customer asking about a new product, for example — will get miscategorized. That's why routing rules matter more than classifier perfection.
• We always include a confidence score. Low-confidence messages get routed to a human review queue instead of being auto-actioned.

Step 3: Draft response generation (with the safety rails on)

For sales and support categories, the system generates a draft reply. It does not send. Let me say that again because it's the most important sentence in this article: the system does not send.

Drafts land in your inbox as actual Gmail or Outlook drafts attached to the thread. Your team opens the thread, sees the draft pre-written, edits if needed, and hits send. Or deletes it and writes their own. The automation's job is to save the 60-90 seconds of staring at a blank reply window, not to replace the person.

What goes into a good draft:

• Your voice. We feed the model 20-40 examples of how your team actually writes. Not a style guide — actual sent messages. The drafts come out sounding like you, including the quirks.
• Real context. For support emails, we connect to your help docs, FAQ, or knowledge base so the draft can reference actual answers instead of hallucinating policies.
• Account data when it matters. For sales, we can pull the prospect's company info; for support, we can pull their order history or account status. This is where the system stops being a toy.
• Hard guardrails. No pricing commitments, no refund approvals, no legal language, no promises about timelines — these are blocked at the prompt level and the draft instead flags the question for a human.

The draft also includes a one-line summary at the top: "Customer is asking about X. Suggested response below. Confidence: high." Your team reads the summary, scans the draft, ships it.

Step 4: Labels, routing, and escalation

Classification without routing is just a fancy folder. The real work is moving the right messages to the right people fast.

A typical routing setup:

• Sales gets labeled, a draft is generated, and the thread is assigned to whoever handles new business. If the prospect mentions a competitor or a deal size above a threshold you set, it pings a Slack channel too.
• Support gets labeled by sub-type (billing, technical, account, shipping — whatever matches your business), a draft is generated against your knowledge base, and the thread is assigned. Anything mentioning words like "cancel," "refund," "lawyer," "BBB," or "chargeback" skips the draft step entirely and escalates with a red flag.
• Spam gets archived and labeled. We don't delete — you can always audit later.
• Other goes to a review queue. A human reads it.

Escalation rules are where you get opinionated. Common ones we build in:

• VIP sender list — known customers, investors, key partners — always skips automation and pings a human directly.
• Sentiment threshold — if the message reads as angry or urgent, the draft is suppressed and the thread is flagged.
• Repeat contact — if the same person has emailed three times in 48 hours, escalate regardless of category.
• Off-hours — drafts are still generated but auto-assignment waits until business hours so customers don't get a 2 a.m. reply that feels robotic.

Step 5: The handback — knowing when to stop

This is the part nobody writes about. A good triage system needs explicit rules for when it should do nothing and let a human handle the thread cold. Ours always include:

• Low classifier confidence (below a threshold you set, usually 0.75).
• Any message containing legal, medical, or financial advice language.
• Threads that have already gone three replies deep — at that point the context is too thick for a model to reliably help.
• Anything the model itself flags as uncertain. We prompt it to say "I don't know" and that response routes to a human instead of a guess.

The goal is not to maximize automation rate. The goal is to automate the boring 70% so your team has time to be excellent on the 30% that matters.

What you get at handoff

At the end of a build (typically 2-3 weeks for a standard inbox), you get:

• The connected automation running on your live mailbox.
• A dashboard showing volume by category, draft acceptance rate, and escalations.
• Documentation for your team on how to give feedback when a draft is wrong — that feedback loop is how the system gets sharper over month two and three.
• A 30-day tuning window where we adjust the classifier and prompts based on what actually shows up.

What you don't get: a system that runs itself forever with no oversight. Inbox automation is a tool your team uses, not a replacement for the team. The businesses that get the most out of it are the ones where someone owns the dashboard and watches the draft acceptance rate weekly.

If you're sitting on a shared inbox that eats two hours of someone's morning every day, this is the build to start with. See how we'd scope it for your business.