Supported by Renada, our HaloPSA partner, we’ve built an AI step into our helpdesk triage process that reads, classifies and prioritises every support ticket the moment it lands. It sets a proposed priority and category, explains its reasoning, and makes it quicker and easier to route every ticket to the right team and get the prioritisation right from the start.
What problem were we trying to solve?
Every ticket that reaches our service desk needs the same first decision made about it: how urgent is this, and who is the best team to fix it. For us, that has meant classifying tickets against our own P1 to P4 levels of IT support, the definitions of urgency behind our service level agreements, and what type of issue is at hand, to then route each one to a team with the right skill set. A server outage that stops an entire office working is a very different priority to one person who cannot print.
That first read has always been a human job. Someone reads what has come in, whether by e-mail, phone, portal or a ticket logged directly by an engineer, decides how urgent it genuinely is, and triages it to the right person. Not only is this a time-consuming task, it presents a single point of failure, meaning it doesn’t scale well as a purely manual step.
How much pain was the old process causing?
Before we automated it, this first read of every ticket was creating problems of its own, even though the job itself was being done well.
- It slowed down the first step. Getting the right team looking at a ticket quickly maximises our chances of resolving the issue effectively, and every ticket had to wait on a person to read, weigh and decide first.
- It depended on one person at a time. If whoever covered dispatch had to be pulled away from other work, the moment they took lunch, went on leave, or were off sick, someone else had to step in and make the same calls just as consistently.
- The judgement call was harder to teach than the process. Is a director without Wi-Fi more urgent than two of eighty staff who cannot reach a shared drive? Getting that weighting right came down to experience built up over time, closer to instinct than a checklist.
- It was repetitive, thankless work. The same decision, made dozens or hundreds of times a day, for every ticket that came through the door, using time that could have gone into higher value work instead.
How does the AI ticket triage workflow actually work?
Every ticket, however it arrives, ends up inside our IT support platform: Halo. We built the automation as a native workflow there, rather than through any separate workflow tooling we use elsewhere.
- A ticket comes in, triggering the automation automatically, whether it was raised through the portal, by e-mail, over the phone, or logged directly by an engineer.
- Its opening details are sent to an LLM as a brand new request, with no memory of any ticket before it, alongside a prompt hardcoded with our SLA definitions, worked examples of each priority, and the fixed list of ticket types it must choose between.
- The model reads the actual problem, works out how widely it is like
ly to affect people, and returns a priority, a category, a written justification, and a confidence rating. - If it cannot confidently match a defined category, it says so rather than guessing, and leaves the ticket for a person to classify from scratch.
- The proposed priority, category and reasoning are written straight onto the ticket, ready the moment a person opens it.
Why is the AI model swappable, and why does it have no memory?
The model behind this sits at arm’s length from us on purpose. Currently we run this workload against OpenAI’s API, but like all of our automated workflows, it has been built to be model agnostic, for example we automated our customer feedback using a different provider entirely. Spreading AI workloads across more than one partner means one provider’s issue never takes down every automated part of the service desk at once.
Each ticket is treated as a fresh, standalone request, with no memory of the ticket before or after it. That is deliberate: if it could learn from what it had seen, it could just as easily learn the wrong lesson, for instance treating an identical fault as less urgent for a smaller client than a larger one. We would rather it judged every ticket on what is in front of it. Instead, we run an internal feedback process that keeps improving the quality of its output through deliberate updates to the prompt itself, rather than letting the model try to learn on its own.
What challenges did we run into?
The same ticket does not always get the same answer. Running an identical ticket through the model more than once can produce a different, though usually adjacent, priority. That is inherent to how a language model reasons about ambiguity, which is why every result still gets a human check.
A vague ticket gets a vague answer. If someone simply reports the internet is not working, with no other detail, the model has nothing to judge scope from, so it defaults to a middle priority rather than assuming the worst.
We chose not to let it guess. If a ticket genuinely does not match any defined category, the automation says so and leaves it for a person, because a false match would be worse than admitting it could not decide.
What access, tools and safeguards did we need?
Building this needed nothing beyond what we already had: API access out to a language model provider, and permission to write back onto a ticket’s priority, category and type fields, all inside our IT support platform rather than separate workflow tooling.
- No memory between tickets. Nothing is carried over from before or after, so past decisions can never quietly bias future ones.
- Resistant to being talked into a false priority. It looks at the actual problem described rather than language designed to sound urgent, and treats a stated job title as one input, not an instant reason to escalate.
- Tuned towards caution, not certainty. When unsure, it leans towards marking a ticket more urgent rather than less, since an over-cautious call is quickly corrected, while an under-called one risks being missed.
- A human reviews every single ticket. Its classification and reasoning are ready on the ticket, but nothing is auto-actioned. It is a first pass for a person to check, never the final word.
- The fallback has already been tested for real. While building this, our AI provider briefly went offline over an unrelated billing issue. Every ticket in that gap simply reverted to manual triage, with no breach of our service levels and nothing a customer noticed.
What results have we seen?
The change has been less about one dramatic result and more about what stopped being a bottleneck. A ticket now carries a proposed priority, category and reasoning within moments of being logged, day or night, whenever our 24-hour IT support is needed.
| Before | After |
| A person read, weighed and classified every ticket before the fix could start | Every ticket automatically carries a proposed priority, category and reasoning within moments, freeing that person’s time for higher value work |
| A single point of failure: one role covering dispatch, vulnerable to lunch breaks, leave and turnover | Consistent first pass triage, whoever is or is not in the building |
| Getting the call right relied on judgement built up over years | Any team member can review the model’s reasoning alongside its answer |
What did we learn from building this?
- Low effort, medium impact, low risk is still a good place to start. This was never going to transform the business on its own, in keeping with the crawl-walk-run approach we take across our automation work. It needed to work reliably and fail safely, and it does.
- A considered fallback matters more than a perfect model. The value is not that the AI always gets it right, it is that when it does not, a person picks the ticket up regardless, and nothing falls through.
- The model does not need to learn, the prompt does. That internal feedback process is what keeps its reasoning improving over time, without the system quietly building bias of its own.
- There is more to explore here. We are already looking at what else this analysis could trigger directly: agentic workflows that could action anything from a hardware replacement request to installing an approved piece of software, though we are taking our time over how far to go.
If there is a manual, repetitive first step in your team’s work that could safely be handed to AI, that is exactly the kind of problem we help clients work through.