How do you triage support requests automatically?

Open the support inbox at nine and count what's there. A few order questions, a billing dispute, two password resets, a complaint, and a customer who is really asking sales for a quote. Before anyone can answer any of them, someone has to read them all, decide who handles each one and open the account to see what's going on. In a team of eight agents that someone is usually the most experienced person, and it takes the first hour of their day.

That reading and sorting is triage. It has less judgment and more repetition than anything else in support work, which makes it a good thing to hand to a system first. This guide covers what an automatic version does, how to set up the lanes, where a person stays in charge and how to tell whether it's working.

What triage involves when it's done by hand

Triage is four jobs done in one pass. Someone works out what type of request it is. They find the customer's order, account or history in another system. They decide which person or queue should take it. And they usually type the first line of a reply that has been typed a hundred times before. Because one person does all four at once, nobody thinks of them as separate jobs, but the first three are mechanical and the fourth mostly is.

The cost lands in two places. The customer waits while the request sits unread. The agent who finally picks it up starts cold, with three or four tabs to open before they can write anything.

What an automatic triage system does

The system reads each request as it arrives, from the shared inbox, the web form or the chat. It puts the request into one of the 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 still open. It sends the request to the lane or person that handles that type. Then it drafts a first reply from your approved answer for that type, with the customer's details filled in.

The agent opens a request that already says what it is, with the account beside it and a draft waiting. They check it, adjust it and send it. For the plainest types, such as a delivery status question, the draft may go out unchanged. For the rest, the agent's edit is where the service happens.

Take a hypothetical customer who writes in to say they've been charged twice. Today an agent reads the email, searches the billing system, finds two transactions and works out whether one of them is a temporary hold before writing back. With triage running, the request arrives in the billing lane marked as a duplicate charge, 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 a line and sends. If the system can't find the account, or finds something it can't explain, the request goes to the unclear lane with a note saying why.

How to decide the lanes

Build the lanes from the requests you get. Export a week of them from your ticketing tool or inbox and sort them by hand into types. Most teams find that a handful of types make up most of the volume: order status, returns, billing, access problems, product questions and a long tail of everything else. Those types rarely match the department names on your org chart, so start from the requests.

• Start with the types that are frequent and easy to recognise. The system will place those correctly 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 where it belongs. A system forced to put every request somewhere will misroute the hard ones.
• Leave the long tail in the unclear lane until one type turns up often enough to earn a lane of its own.

Triage usually sits in the frequent, low-judgment group described in which AI use case to fund first, which is why it's often the first project for a service team.

Attach the context before anyone reads it

This is the step customers feel. A request that mentions an order number gets the order attached. A request from a known email address gets the account, the plan and the last few conversations. The agent doesn't have to ask for anything your systems already hold, and the customer doesn't have to repeat themselves.

It depends on your systems having a way to be read, so check that before you commit. A CRM, an order system and a ticketing tool usually do. A spreadsheet of key accounts kept by one team lead doesn't, and moving it somewhere the system can read is a small job to do first.

The first reply is drafted for an agent to send

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, then leaves the draft for the agent. Starting from a good answer means the reply goes out sooner. When agents keep changing the same line in a draft, the approved answer needs rewriting, and you fix it once at the source.

Keeping the send with a person also stops a confident wrong answer reaching a customer. For a team that has worked hard on its reputation, that's the risk worth designing around.

Where a person stays in charge

Some requests shouldn't be routed by a rule at all. Anything angry, anything about a refund or a credit, anything that mentions a lawyer or a contract dispute, and anything the system isn't sure about goes straight to a person with the context attached and no draft. The system's job there is to get the request to the right person quickly, with everything they need.

Agents also correct the system. When a request lands in the wrong lane, the agent moves it. Someone reviews those moves each week and turns them into changes to the rules. Over the first few weeks the share of re-routed requests should fall. If it doesn't, the lanes need redrawing, which is a job for the team lead and whoever runs the system, together.

What to measure

Take the readings before anything changes. Time to resolve is the one customers feel. The share of requests resolved by the first person who touches them tells you whether the context and drafts are doing their job. The share re-routed after the system placed them tells you whether the lanes are right. And watch the first hour of your most experienced agent's day, because that's where the time comes back. How to measure AI ROI covers turning readings like these into a figure your finance lead will accept.

What to do this week

1. Export a week of requests and sort them by hand into types. Count each type.
2. For the five biggest types, write down which system an agent opens to answer them and the first line they always type.
3. Name an owner for each lane and write its approved first reply.
4. Decide what goes to the unclear lane and who reads it.
5. Take today's readings: time to resolve, requests resolved at first touch, and how long the morning sort takes.

Getting triage live in a working support team is mostly deployment work: connecting the inbox to your systems, setting up the lanes and drafts with your agents, and running the weekly review of corrections until the re-routed share settles.

Get the next article when it's published.