Customer support

Intelligent Support Triage Console

Classify and route inbound support with a human in the loop: agents own every reply, and deflection only counts when the problem stays solved.

Scale
Medium
Platforms
Web
Capabilities
AI · Automation · B2B · Internal tools

The premise

Inbound support is a routing problem before it is an answering problem. Most of the pain in a support queue is not that answers are hard — it’s that the billing question sat in the technical queue for a day, the urgent thread looked routine, and the third message about the same outage was handled as if it were the first. The console starts there: classification, priority, and routing, with generation strictly downstream of a human.

Human-in-the-loop by construction

From inbound message to owned reply
  1. Message arrives email, chat, form — one queue
  2. Classify & prioritize category, urgency, confidence shown
  3. Route to the right queue; low confidence routes to a human sorter
  4. Draft prepared grounded in docs and account context
  5. Agent reviews & sends edits tracked; the agent's name on it
  6. Outcome recorded reopens and follow-ups traced back

Classification confidence is visible, and low confidence is a feature: uncertain messages go to a human sorter instead of a probably-wrong queue. Misroutes are one click to correct, and every correction is training signal.

Drafts that agents own

The console prepares a reply grounded in documentation and the customer’s account context — but the agent sends it, under their own name, after edits the system tracks. Ownership is not a courtesy; it is the quality mechanism. An agent who signs a reply reads it; a team whose edits are measured reveals exactly where drafts are weak. Draft acceptance rate is a health metric for the system, not a performance metric for the agent — the moment those get confused, agents stop editing and quality quietly dies.

Measuring deflection honestly

Deflection is the most gamed metric in support. A customer bounced to a help article who silently gives up counts as a success in most dashboards and is, in reality, a hidden churn event. The console treats deflection as a claim to be verified: a self-served resolution counts only if the customer doesn’t return on the same issue within a defined window, and “deflected” threads are sampled for follow-up satisfaction checks. The reporting distinguishes resolved without an agent from disappeared without an answer — and the second number is displayed just as prominently.

Escalations AI cannot close

Some paths are structurally closed to automation: legal threats, safety concerns, regulatory complaints, billing disputes above a threshold, and any thread showing real distress. These hard-route to designated humans, and the system cannot mark them resolved, summarize them into closure, or auto-reply into them. This is enforced in the state machine, not the prompt — a category of ticket the model cannot touch is a guarantee; a category it is instructed not to touch is a hope.

Shape of the build and evaluation

A prototype needs one inbound channel, one team’s category taxonomy, the routing loop with confidence thresholds, and the draft-review flow. Evaluation hypotheses: routing accuracy on a labeled historical sample (target: beats the team’s current rule-based routing); draft edit distance trending down over weeks without agent send-time rising; honest-deflection rate reported alongside raw deflection — and a standing audit that no structurally-escalated thread was ever closed by anything but a person.

Facing a similar problem for real?

This study's reasoning — discovery, architecture, evaluation — is exactly what a HummingByte engagement looks like. Bring us the real version.