We've now deployed support routing agents at eight different companies, ranging from a twenty-person SaaS to a regional logistics firm with several hundred staff. Some of the deployments went smoothly. Others revealed things we didn't anticipate.
These are notes on what actually happens, written six months after our most recent one went live. The numbers here are real; the company name isn't included at their request.
What the numbers looked like before
The client handled around 340 support tickets per week across two support staff. About 60% of those were what they called "tier-1" — questions with a known answer, routing to the right team, or straightforward status updates. The support staff spent roughly half their working hours on these, which left them stretched on the more complex tickets that actually needed attention.
This is a familiar pattern. The work that's easy to automate takes up the same amount of time as the work that isn't, because both arrive as undifferentiated email.
What we built and how it runs
The agent reads incoming tickets as they arrive. For each one, it classifies the topic (billing, product, technical, account, other), checks the knowledge base for a relevant answer, assesses confidence on a 0-1 scale, and then branches:
If confidence is above 0.85 and the topic has a standard response template: the agent drafts a response, routes the ticket to the relevant queue marked as "draft ready," and notifies the assigned agent. No response goes out automatically — a human reviews it before it sends.
If confidence is between 0.6 and 0.85: the agent routes the ticket with a summary of what it thinks is the issue and a list of the three most relevant knowledge base articles. The human takes it from there.
Below 0.6, or if the ticket contains sentiment signals indicating a frustrated customer: the ticket goes straight to a senior support agent with a flag.
Six months in
The agent handles the drafting step on about 58% of incoming tickets. The support team's review of those drafts takes on average less than ninety seconds each. On the remaining 42%, the agent's classification and routing summary is still saving time even though the response needs to be written from scratch.
We did have one rough patch in month three. The client ran a product promotion that created a ticket category that hadn't existed before — promo code issues — and the agent was routing these as billing tickets, which was wrong. The fix took about two hours once we identified it, but it meant about four days of slightly odd routing before anyone caught it. Monitoring would have caught it faster; we've since added an anomaly alert when any category's ticket volume shifts more than 30% week-over-week.
What to measure and why
The metric that matters most isn't automation rate. It's the error rate on automated actions — specifically, how often a draft response gets materially rewritten by the human reviewer before it goes out. A high rewrite rate means the agent's drafts aren't close enough to be useful. The target we work toward is under 15% material rewrite on draft-ready tickets. Above that, the "draft" is adding noise rather than saving time.
The other thing worth tracking is escalation rate over time. If the agent is escalating fewer tickets as months go on, the knowledge base is getting richer and the confidence model is improving. If escalation rate stays flat, the knowledge base isn't being maintained.
Neither of these metrics shows up in a "tickets automated" dashboard. You have to build them in deliberately.