Support triage with replies ready for review
Incoming tickets are categorised and routed, with suggested replies drawn from the team's help documents. Agents review and send.
Results
- from a ticket arriving to a draft reply in the agent's queue
- Under 2 minutes
- of tickets routed to the right queue on the first pass
- 91%
- of drafts sent as they were or with a light edit
- 62%
- of sampled sensitive requests reached a person before any reply
- 100%
Measured over the first three months on about 1,200 tickets a month, with a weekly sample of 50 tickets graded by the support team.
Sorting, routing and drafting run when the ticket arrives. Checking the draft and sending it stay with the agent, and sensitive requests never get a draft at all.
The problem
Agents had to categorise, tag and route incoming tickets before they could start resolving them. Repeated questions also meant drafting the same kinds of replies.
Every ticket started with sorting. An agent read the message, picked a queue, added tags and set a priority before anyone could answer it. On a busy morning that was the first hour of the day.
The same questions came back every week, such as password resets, invoice copies and delivery status. Each one got a reply typed from scratch or pasted from a personal snippet file, so the answers drifted away from the help documents.
Sensitive cases were the worry. A complaint or a request to close an account needs a person straight away, and a queue sorted by hand can bury it. The project brought the preparation steps into the existing helpdesk and left the decision to edit and send with the agent.
What we built
The workflow prepares the ticket and a suggested reply inside the existing support process.
- Categorise and prioritise incoming emails and form submissions.
- Route tickets with consistent tags.
- Draft suggested replies from the team's approved help documents.
- Flag ambiguous or sensitive requests for a person.
How we built it
- Wrote the routing scheme down with the support lead: eight queues, the tags that change who handles a ticket, and twenty examples of tickets that are hard to place.
- Built the intake step. Each email or form submission is categorised, given a priority and routed with consistent tags.
- Connected the approved help documents so every draft cites the document it drew from. If no document covers the question, the ticket gets a note instead of a draft.
- Added a fixed rule for sensitive requests. Complaints, account closures and anything that mentions a regulator or a lawyer skip the draft and go to a person.
- Set up the weekly sample. A senior agent grades 50 tickets for routing and draft quality, and the results go on a shared dashboard.
What changed
Agents receive a sorted queue and a draft they can check or edit. Ambiguous and sensitive questions remain with a person.
Agents open a sorted queue with a draft attached to most routine tickets. They read the customer's message, check the draft against it, then send or edit. Nothing reaches a customer until an agent presses send.
The weekly sample kept the numbers honest. Routing accuracy started at 84% and reached 91% after we merged two queues that overlapped. Draft acceptance rose as the team retired the outdated help documents the drafts kept surfacing.
We underestimated how much of the value sat in the sample rather than the drafting. The grading exposed stale help content and a queue nobody owned. Both were problems before the project and invisible until then.
How the workflow fits together
What we measured and how
Each figure in the results block comes from one of these measurements.
| What we measured | How | Result |
|---|---|---|
| Time to a draft reply | Helpdesk timestamps, from the ticket being created to the draft being attached. | Median under 2 minutes for routine tickets |
| Routing accuracy | A weekly sample of 50 tickets, each checked against the agreed scheme by a senior agent. | 91% correct on the first pass, from 84% in month one |
| Draft acceptance | The sent reply compared with the draft and grouped: sent as it was, light edit, rewritten, or no draft. | 62% sent as they were or with a light edit |
| Sensitive requests | The fixed rule, plus a weekly review of every flagged ticket and a search of the sample for missed ones. | All sampled sensitive requests reached a person before any reply |
Planning a similar project
These are questions to resolve with your team before implementing a similar workflow.
| Decision | What to establish |
|---|---|
| Queue decisions | Which tags and priorities change who handles the ticket? Start with a small, agreed routing scheme and examples of difficult requests. |
| Reply sources | Which help documents are approved and who maintains them? Decide what happens when a source is missing, outdated or does not answer the question. |
| Review quality | Which cases must reach a person immediately? Sample the routing and the drafts separately so a good-looking draft does not hide a routing error. |
Questions about this workflow
Are replies sent without an agent checking them?
No. The workflow prepares a draft for review. The agent checks it, edits it if needed and sends it. The workflow cannot send a reply on its own.
What happens to ambiguous or sensitive requests?
They are flagged for a person and skip the draft. The workflow prepares routine tickets and leaves uncertain or sensitive questions to human judgement.
How should a team evaluate support automation?
Grade routing accuracy, the share of drafts sent or edited, and the time agents spend resolving tickets. This case used a weekly sample of 50 tickets graded by a senior agent. Check the difficult and sensitive cases as well as the common questions, because faster drafting alone does not show better support.
Discuss your workflow.
Tell us which systems your team uses and where the work gets stuck.