How we use AI inside our own helpdesk (and where we don't)

It is easy to recommend AI to other people. It is more honest to use it on yourself first.

Before we offered AI automation to clients, we put it to work in our own operations at Cloud ITS. Our helpdesk was the obvious place to start: it is where we spend most of our day, where small delays are felt most by clients, and where we could see the results directly.

This is an account of what we built, what we deliberately chose not to build, and what we would tell any business considering the same step.

Why we started with ourselves

There were three reasons.

First, credibility. If we were going to advise a 30-person accounting practice or engineering firm on where AI pays off, we wanted to speak from experience, including the mistakes.

Second, risk. Our helpdesk handles tickets from businesses across finance, legal, medical, engineering and other sectors. If we could design safe guardrails for that, we would understand what safe looks like for clients.

Third, the work suited it. A helpdesk has exactly the kind of repetitive, rules-plus-judgement work we describe in where AI automation actually pays off: high volume, consistent structure, and a real cost when something is miscategorised or missed.

What the AI does: triage suggestions

Every ticket that arrives in our HaloPSA helpdesk, whether by email, phone log or portal, is read by an AI model. It proposes three things:

1. A category, such as email, Microsoft 365 account, printer, network, backup or security.
2. A priority, based on what the ticket describes. “One user can’t print” is different from “nobody at the branch can connect”.
3. A plain-language summary of what the client needs, in a sentence or two, so an engineer can understand the issue at a glance without reading a long forwarded thread.

Then an engineer looks at the suggestion and confirms or corrects it. Nothing happens to the ticket until a person has done that.

This matters more than it might seem. The AI is quick and usually sensible, but it does not know that a particular client’s “small issue” affects their only server, or that a message which sounds routine comes from a director who is travelling and can’t work. Our engineers do. The suggestion saves them reading time; the decision stays theirs.

What the AI does: alert correlation

We monitor client environments around the clock: firewalls, servers, backups, endpoint protection and more. When something goes wrong, it rarely produces just one alert. An internet outage at a client site can trigger alerts from the firewall, the VPN, the backup job and every device that lost its connection.

Without correlation, an engineer sees a dozen alerts and has to work out that they share one cause. Our system groups related alerts into a single incident, so the engineer starts with “this site appears to have lost connectivity, and these alerts follow from it” rather than a wall of red.

Again, the grouping is a suggestion. An engineer can split an incident if two unrelated problems happen to coincide.

What we deliberately do not let AI do

This list was as much work to agree as the features themselves.

• Close tickets on its own. A ticket is only closed when a person is satisfied the issue is resolved. An AI deciding that a problem “looks fixed” is exactly how clients end up feeling ignored.
• Touch client systems unsupervised. The AI does not reset passwords, change firewall rules, modify Microsoft 365 settings or run scripts on client machines by itself. Any change to a client environment is made or approved by an engineer.
• Talk to clients without a person. Clients do not receive AI-written messages that nobody has read. An AI may help an engineer draft a clearer update, but a person reviews it and sends it under their own name.
• Make final calls on security incidents. Our SentinelOne and firewall alerts can inform the AI’s grouping, but deciding whether something is an attack, and what to do about it, is an engineer’s job.

Our rule is simple: AI can read, sort, summarise and suggest. People decide, change and communicate.

The guardrails behind it

A feature is only as safe as the rules around it. Ours include:

• No client secrets in prompts. Passwords, recovery keys, API keys and similar credentials are never sent to the AI model. Our processes and tooling are designed to keep them out, and engineers are trained to treat this as non-negotiable.
• Minimum necessary information. The model receives what it needs to triage a ticket, not a client’s whole history or file system.
• Logging. We keep a record of what the AI suggested and what the engineer decided. That lets us see where suggestions are consistently good and where they go wrong.
• Regular review. We periodically look at corrected suggestions to understand patterns, for example a category the model keeps confusing, and adjust our setup accordingly.
• Business-grade services only. We use AI services under business terms, not consumer accounts. The same principle is in our guidance on POPIA and AI tools.

What changed for our clients

We are wary of quoting figures from our own system as if they were independent research, so we will describe the change rather than measure it here.

• Faster first response. Tickets arrive already categorised and summarised, so the right engineer picks them up sooner and can respond with something meaningful rather than “we’ve received your request”.
• Clearer updates. Because engineers start from a plain-language summary, the update a client receives tends to describe their problem in their terms.
• Less noise during outages. When a site goes down, clients hear about one incident with one owner, not a flurry of separate tickets.
• More engineer time on actual fixing. Reading and sorting is the part of the day our engineers least missed.

None of this replaced a single engineer. It changed where their attention goes.

What we would tell any business adopting AI

The same lessons apply whether you run a helpdesk, an accounting practice or a law firm.

1. Start with your own pain, not the tool. Pick a workflow where you already know the cost of doing it badly.
2. Make human review the default. Let people confirm suggestions until you have evidence about where the AI is reliable.
3. Decide what AI may never do, in writing, before you build anything.
4. Keep sensitive data out by design, not by hoping people remember.
5. Log and review. If you cannot see what the AI suggested, you cannot improve it or defend it.
6. Fix the foundation first. Our AI work sits on a managed-IT base of Microsoft 365 with MFA and Conditional Access, endpoint protection, tested backups and documented systems. Without that, automation simply moves risk around faster.

The same thinking runs through the governed AI assistants we build for professional firms, and the work we do integrating, hosting and supporting Silk, the AI workbench for South African law firms from our sister company Tailored Intelligence.

Curious what this could look like for you?

If you would like to know which of your own workflows could benefit from the same approach, our free Automation & Risk Check is a 30-minute conversation about where automation would genuinely pay off, plus a look at your backups, security and documentation. You receive a one-page report, with no obligation attached.