The whole design fits in a paragraph. Point support@ at a workflow. The workflow sorts every message into a type, answers the documented questions from your own material, gathers the details on bug reports so an engineer doesn’t have to interrogate the customer, drafts refund decisions for a human to approve, and hands anything complicated or angry straight to a person.
The rest of this is the detail that decides whether it works.
The four branches
Support inboxes are more repetitive than they feel from the inside. Nearly all of them come down to one sorting step and four paths.
Sorting comes first, and it’s the step to get right. Product question, bug report, refund request, other. Keep the list short. Every downstream decision hangs off this one, so a sloppy category list produces a workflow that’s confidently wrong in a way that’s hard to debug.
Product questions get answered from your material. “How do I export my data” is already documented. The agent finds the passage and writes a reply from it. If your docs don’t cover the question, it doesn’t improvise — the thread goes to a person, which is the correct behaviour and also the one people forget to configure.
Bug reports get pulled apart before a human sees them. Product area, what the customer did, what happened, what account, what browser. The customer gets a short acknowledgement with a reference. Your engineer gets a summary instead of “it’s broken”. There’s no built-in issue-tracker integration, so filing it is either a person’s click or something your own tooling does through the API — but the reading and the extraction are already done.
Refund requests get a draft and a queue. The agent compares the request to your written policy, drafts the decision either way, and attaches the reasoning. A human approves, edits or rejects. Money doesn’t move without someone’s name on it.
Anything that doesn’t fit those four — or that the sorting step wasn’t confident about — goes to a person untouched. No tagging it as “other” and hoping.
The escalation rules worth hard-coding
The hard part of support automation isn’t teaching an agent to answer. It’s teaching it when to shut up.
Write these as conditions, not as things you hope the model will infer:
- Emotional language. Frustration, sarcasm, “this is the third time I’ve written”. A person answers, every time. A technically correct robot reply to a furious customer reads as an insult, and they were already halfway out the door.
- Security reports. Whoever writes in about a vulnerability needs a human fast. The agent’s entire job here is to confirm receipt and get out of the way.
- Money in dispute. Chargebacks, billing errors, refunds outside the policy. A draft at most, usually not even that.
- Legal and compliance signals. Lawyers, regulators, data deletion requests. These leave the automation completely.
- Low confidence. When the classifier can’t tell which branch a message belongs to, that uncertainty is the trigger. The default is a human, never a guess.
There’s one test that covers all of these. A slow correct answer costs you a few minutes. A fast wrong one can cost you the customer. So design every failure mode to end in “a person replied a bit later”, and none of them to end in “the AI said something stupid”.
Keeping it sounding like your team
The fear here is reasonable: nobody wants support@ to start sounding like a chatbot from 2019. Three things prevent it, and they’re layered rather than alternatives.
Templates set the shape — your greeting, your structure, your sign-off. The agent fills those in rather than composing from scratch in whatever register it feels like, so the reply looks like your team’s because structurally it is.
Your own material sets the facts. The agent answers from your docs, your saved answers, your written policy, and from nothing else. If your docs say an export can take an hour, that’s what the reply says. If your docs don’t mention exports, the reply doesn’t either.
And the approval queue sets the pace. Early on, everything waits. You read the drafts, fix the ones with the wrong tone, and notice the pattern in what you’re fixing. Some branches will turn out to need almost no edits — FAQ answers, usually — and those are the ones you let go first. Refunds stay behind the gate more or less forever. Trust gets handed over one category at a time, which is exactly how you’d onboard a person.
Knowing whether it’s working
The number that matters most isn’t resolution rate, it’s how often you approve a draft without changing it, tracked per category. A category where you never edit is a category ready to send itself. A category where the edit rate suddenly climbs means a snippet has gone stale — a price changed, a policy moved — and the agent is faithfully repeating something that stopped being true.
Watch first-response time too, because it’s the number customers actually experience, and it improves immediately for the obvious reason. Then watch the escalations: of the threads sent to a person, how many really needed one, and of the ones answered automatically, how many did a human end up taking over anyway? The second kind of mistake is the expensive one.
More on the operating side of this — the rollout, the guardrails to demand from any vendor — is on agentic support, explained.
Three ways the first attempt goes wrong
Automating before the policy exists. If your refund rules live in one person’s head, there’s nothing for the agent to check requests against and it will fill the gap with something plausible. Write the policy first. The document you write is the same one the workflow reads, so it isn’t wasted effort even if you stop there.
Letting it answer angry threads. The classifier can spot frustration. It cannot repair a relationship. Send these to people without exception, and don’t make it a confidence threshold — make it a rule.
Ignoring your own edits. If someone rewrites the same draft the same way every week and nothing changes, you’ve automated the first draft and nothing else. Every edit is a signal about a template, a missing snippet, or a branch that’s wrong. Treat it as one.
The pattern here — sort, act, gate, escalate — isn’t support-specific. It’s the same shape for sales and hiring mail, and the condensed version for support@ is on the customer support use case.