CASE STUDY · AI-NATIVE REWRITES OF LEGACY SAAS (CRM/ERP/ITSM)
Modernizing an ITSM tool with autonomous ticket triage.
- 4 hoursFirst response down from 4 hours to 35 minutes
- 40%40% of tickets resolved without a person
01 · PROJECT OVERVIEW
The client and the brief.
An anonymised mid-market B2B services company. Name withheld under confidentiality.
A triage agent that categorises, routes and resolves common requests, escalating the rest to people. For routine categories the agent could complete the task through the company's approved tools, with a log of each step. For anything unclear, sensitive or outside its remit, it passed the ticket to a person with a summary.
- 11,200 tickets a month and slow routing.
- 2Every ticket landed in a shared queue, where a coordinator read it, picked a category and assigned it.
- 3Many requests were routine: access requests, password problems, standard software installs.
- 4They waited behind urgent ones.
- 5Staff were frustrated, and users had little idea when to expect a reply.
02 · WHAT WENT WRONG
What went wrong, and how we fixed it.
Every engagement hits problems. These were the ones that mattered here, and what we changed so they did not come back.
- PROBLEM 01In shadow mode, the agent mislabelled a group of access requests as simple, when they needed manager approval
It would have granted access that should have been checked. Because we were running in shadow mode, no harm was done. We added an approval-check step that looks up the manager's sign-off before any access action, and moved all access requests to approval-required until the check had proved itself over several weeks.
- PROBLEM 02We added an approval-check step that looks up the manager's sign-off before any access action, and moved all access requests to approval-required until the check had proved itself over several weeks
- PROBLEM 03A second hurdle came from the resolution step
The agent correctly identified a routine software request, but the install tool timed out and the agent reported the ticket as resolved. The user came back two days later. We changed the agent so it only closes a ticket after checking the outcome with the target system, added a retry with a limit, and set it to hand the ticket to a person if the check failed.
- PROBLEM 04Closure now depends on a verified result, not on the agent's own report
03 · THE PROCESS
How we ran it.
- 01Weeks 1 to 2
Analysed several months of past tickets, grouped them into categories and identified which could be handled safely by an agent.
- 02Weeks 3 to 5
Built classification and routing in shadow mode. The agent made a call on every ticket, but only coordinators acted. We compared its calls with theirs daily.
- 03Weeks 6 to 8
Turned on routing, then automatic resolution for two simple categories with logging.
- 04Weeks 9 to 11
Added more categories one at a time and set up the review process.
- 05After launch
Weekly review of escalations and wrong calls.
04 · RESULTS
What changed.
Measured against the way the work ran before the engagement began.
- NOW 01
Coordinators no longer sort the queue by hand.
- NOW 02
They handle escalations and review a sample of the agent's work each week.
- NOW 03
Support staff spend more time on harder problems and on fixing the causes of repeat requests.
- NOW 04
New request types are added to the agent in a controlled way, tested on past tickets first.
- 4 hours
First response down from 4 hours to 35 minutes
- 40%
40% of tickets resolved without a person
05 · WHAT WE BUILT
How it works.
- A queue listener received each new ticket and passed it to the classifier, which returned a category, a confidence value and a short reason.
- Policy rules mapped category and confidence to an action: route, resolve or escalate.
- Resolution used narrow tools with limited permissions, such as a request to reset a password through the identity system, not a general admin account.
- The agent never acted on tickets that mentioned certain sensitive topics or came from named executives.
- Those went to a person.
- Every action, tool call and result was logged on the ticket.
- Controls after launch
- Each week a coordinator reviews a random sample of tickets the agent resolved and all tickets that were reopened. A dashboard shows categories, confidence levels, escalations and reopen rates. If reopen rates for a category rise above the agreed level, that category returns to approval-required mode until the cause is found.
- Handover
- The service desk lead learned to add a category, write its policy rule and test it on past tickets. Two engineers received the documentation for the queue listener, the tools the agent can call and their permissions. The runbook explains how to pause the agent, which takes one switch and sends all tickets back to the manual queue.
06 · QUICK ANSWERS
The short version.
- What problem did the client have?
- 1,200 tickets a month and slow routing. Every ticket landed in a shared queue, where a coordinator read it, picked a category and assigned it. Many requests were routine: access requests, password problems, standard software installs. They waited behind urgent ones. Staff were frustrated, and users had little idea when to expect a reply.
- What did Brandsmashers build?
- A triage agent that categorises, routes and resolves common requests, escalating the rest to people. For routine categories the agent could complete the task through the company's approved tools, with a log of each step. For anything unclear, sensitive or outside its remit, it passed the ticket to a person with a summary.
- What were the results?
- First response down from 4 hours to 35 minutes; 40% of tickets resolved without a person.
YOUR TURN
Have a similar requirement?
Tell us what is stuck. We will come back with a plan and matched, pre-vetted engineers.
