How do you triage support requests automatically?

Open the support inbox at nine and count what's there. Order questions, a billing dispute, two password resets, a complaint, a request from a customer who is really asking sales a question. Before anyone can answer any of them, someone has to read all of them, decide who should handle each, and open the account to see what's going on. In most teams that someone is the most experienced agent, and it eats the first hour of their day.

That reading and sorting is triage. It's the part of support work that has the least judgment in it and the most repetition, which makes it the first thing to take off a person's plate.

What triage is doing today, by hand

Break it down and triage is four separate jobs. Working out what type of request it is. Finding the customer's order, account or history in another system. Deciding who or which queue should take it. And, usually, typing the first line of a reply that has been typed a hundred times before. An agent does all four in a single pass, so nobody sees them as separate. But they are, and the first three are mechanical.

The cost shows up in two places. The customer waits while the request sits in a pile. And the agent who finally picks it up starts cold, with four tabs to open before they can write a word.

What an automatic triage system does

The system reads each request as it arrives, from the inbox, the web form or the chat widget. It classifies it into one of the request types you've defined. It looks the customer up in your CRM or order system and attaches the matching record, the recent history and anything open. It routes the request to the lane or person that handles that type. And it drafts a first reply from your approved answer for that type, with the customer's details filled in.

What the agent sees is a request that already says what it is, with the account open beside it and a draft waiting. They check, adjust and send. For the plainest types, a status question for instance, the draft may be good enough to go without a change. For the rest, the agent's edit is where the service happens.

Take a billing request as an example. A customer writes to say they've been charged twice. Today, an agent reads it, searches the billing system for the account, finds two transactions, checks whether one is a pre-authorisation, and writes back. With triage running, the request arrives in the billing lane already marked as a duplicate-charge query, with the account and the last two transactions attached and a draft that explains the difference between a hold and a charge. The agent confirms which case it is, edits one line, and sends. If the system can't find the account or finds something odd, the request goes to the unclear lane instead, with a note saying why.

Deciding the lanes

The lanes are the request types your team gets, not the departments on the org chart. Pull a week of requests and sort them by hand. You'll usually find a handful of types that make up most of the volume: order status, returns, billing, access problems, a product question, and a long tail of everything else.

• Start with the types that are both frequent and clear. Those are the ones the system will get right from the first week.
• Give each lane an owner or a queue, and an approved first reply.
• Add an unclear lane. Anything the system can't place with confidence goes there, and a person decides. This lane is part of the design. A system that forces every request into a lane will misroute the hard ones.
• Keep the long tail in the unclear lane until a type appears often enough to deserve its own.

The first reply is drafted, not sent

Each lane has an approved first reply, written by your team in your voice. The system fills in the customer's details and whatever it found in your systems, then leaves the draft for the agent. This matters for two reasons. The agent starts from a good answer instead of a blank box, so the reply goes out sooner. And the draft is only ever as good as the approved answer behind it, so when agents keep changing the same line, you've found an answer that needs rewriting at the source. Keeping the send with a person is also what stops a confident wrong answer reaching a customer, which is the fastest way to lose one.

Attaching the context

This is the step customers feel. If a request mentions an order number, the order is attached. If it comes from a known email address, the account, the plan and the last three conversations are attached. The agent never asks for what your systems already know, and the customer never has to repeat themselves.

It depends on your systems having a way to be read, which is worth checking before you commit. A CRM, an order system and a help desk usually do. A spreadsheet on someone's laptop doesn't, and that's a thing to fix first rather than a reason to wait.

Where a person stays

Routing is a decision, and some decisions should not be made by a rule. Anything angry, anything about money going back, anything with a legal word in it, and anything the system isn't sure about goes to a person with the context attached and no draft sent. The system's job in those cases is to get the request to the right person fast, with everything they need, and then step aside.

Agents also correct the system. When a request lands in the wrong lane, the agent moves it, and those moves are reviewed each week and turned into changes to the rules. Over the first weeks the share of re-routed requests falls, and that number is your evidence the triage is working. If it doesn't fall, the lanes are wrong, not the agents.

What to measure

Take the readings before anything changes. Time to resolve a customer request, from the measures on Customer Experience, is the one the customer feels. Requests handled without escalation tells you whether the first person to touch a request could finish it. Add the share of requests re-routed after the system placed them. And keep an eye on the first hour of the senior agent's day, because that is where the capacity comes back.

What to do this week

1. Export a week of requests and sort them by hand into types. Count each type.
2. For the top five types, write down the system an agent opens to answer them, and the first line they always type.
3. Decide who owns each lane and write the approved first reply for it.
4. Define the unclear lane and who reads it.
5. Take the readings: time to resolve, requests handled without escalation, as they stand now.

If you'd like us to look at the week of requests with you, that's a good first call. We'll tell you which types we'd automate the triage for first, which we'd keep with a person, and how we'd measure it. The wider question of how to use AI in support without a backlash is covered in this post.