Help desk automation is usually scoped by difficulty. Automate the easy tickets, escalate the hard ones. It is an intuitive rule and it fails in a specific way, because some of the most consequential tickets in the queue are the simplest to read.
A password reset and an access request can arrive in almost identical words. One is a routine identity check. The other is a decision about whether a person should be able to see something, and no amount of natural-language understanding turns that into a lookup. Difficulty is the wrong axis.
The line that holds is whether the ticket asks for an action or a decision. Actions have a correct outcome you can verify. Decisions require someone to weigh whether the outcome should happen at all. This AI-driven help desk guide covers the five ticket types that fall on the decision side, plus the one genuinely worth automating first.
Start With What Should Be Automated
Nothing here is an argument against help desk automation. Password and account-unlock requests routinely account for something close to a third of ticket volume at smaller organisations, they are highly repetitive, and they have a verifiable success condition. That combination makes them the clearest case for automation in the whole queue, and handling them well frees your team for work that actually needs judgment.
Three conditions make automated resets safe rather than a new weakness: require multi-factor verification before the reset, synchronise the change with the authoritative directory rather than one system, and log every reset and unlock as a security event. Without those, self-service resets become a convenient path for anyone who can convince the system they are somebody else.
Ticket classification and routing are also good candidates, as is drafting a suggested response for an agent to review. Those either produce a reversible outcome or keep a human in the path. Everything below is different.
1. Access and Permission Requests
The first and most important exclusion. A ticket asking for access to a shared folder, a finance system, or an admin console reads like a service request and is really an authorisation decision.
Answering it correctly requires knowing whether this person’s role justifies this access, whether granting it breaks a separation-of-duties rule, whether it should be time-limited, and who is accountable if it turns out to be wrong. None of that is in the ticket. It lives in organisational context an automated system does not hold, and the failure mode is silent: access is granted, nothing breaks, nobody notices, and the over-permissioned account sits there until it matters.
Automate the mechanics if you like. Route the request, look up the manager, prepare the change, and stage it. The approval stays human, and the record of who approved it is the point.
2. Departures and Offboarding
Offboarding tickets fail in both directions, which is what makes them unsuitable for hands-off automation.
Act too fast and you cut someone’s access mid-handover, or during a notice period they are still working. Act too slowly and a departed employee keeps mailbox and file access for weeks. Both happen regularly, and the correct timing is a business fact nobody wrote in the ticket.
There is a further wrinkle that automation handles badly. A departure sometimes carries a legal hold or an investigation, which means the mailbox and files must be preserved rather than deleted, and the standard cleanup is exactly the wrong action. That is not an edge case a script should be inferring. Firms with professional obligations feel this most sharply, which we touch on in our guide to help desk support for law firms.
3. Anything That Might Be a Security Incident
A user reporting a suspicious email, an unexpected login prompt, or a file they cannot open is potentially reporting the early stage of an incident. These tickets look mundane and are frequently the only warning you get.
Two things go wrong when automation handles them. The obvious one is a plausible canned answer that closes the ticket, so a real compromise is filed as resolved and the user learns not to bother reporting. The subtler one is that the automation itself becomes a target. An attacker who understands your bot can phrase a request to obtain a reset, an unlock, or a session in a way that a human agent’s instinct would have caught.
Route anything with a security signal to a person immediately and let it interrupt them. Automation can help by recognising the signal and escalating fast, which is genuinely valuable. It should not be composing the reply. Our 24/7 emergency IT help desk exists precisely because these cannot wait for the queue.
4. Tickets Where Someone Is Already Frustrated
The fourth category is defined by the person rather than the problem. A ticket that has been reopened twice, a request from someone who missed a deadline because of an outage, an executive escalation before a client meeting.
The technical issue may be simple. The interaction is not. A correct, cheerful, automated reply to somebody who has explained the same problem three times reliably makes things worse, and the cost lands on your relationship rather than on your systems. People will forgive a slow fix far more readily than they forgive feeling processed.
This is worth encoding as a rule rather than leaving to judgment, because it is easy to detect: reopened tickets, tickets with several exchanges, tickets breaching their service target, and anything from a named escalation list go to a human. Client-facing businesses should be strict here, a theme in our notes on help desk support for accounting firms and real estate firms.
5. Problems Nobody Has Seen Before
The last exclusion is the novel ticket, and it is the one most often overlooked because it is defined by absence.
Automation answers from what it has seen. Faced with genuinely new symptoms it produces the nearest familiar answer, delivered with the same confidence as a correct one. The user follows it, it does not work, and they either give up or open a second ticket that looks unrelated to the first.
The real loss is the signal. The first three tickets about a new fault are how you learn that something changed, and they are most valuable when they reach a human who notices they are related. Automated confident answers scatter that pattern into resolved tickets nobody reviews. A system that says it is not sure and hands over is worth far more than one that always answers, so measure how often yours declines rather than only how often it resolves. Organisations running lean IT feel this most, which we cover in help desk support for nonprofits and for manufacturers.
Applying the Action-Versus-Decision Test
Before automating any ticket type, ask what the requester actually wants:
- An action with a verifiable correct outcome. A reset, an unlock, a status lookup, a licence assignment against a defined rule. Automate it, with identity verification and logging.
- A decision about whether something should happen. Access, permissions, exceptions, departures. Automate the preparation and keep the approval human, so the record shows who decided.
- An interpretation of something ambiguous. Possible incidents, novel faults, frustrated people. Route to a human quickly and let automation earn its value through speed of escalation rather than by answering.
The practical benefit of this test is that it survives your tooling getting better. Automation improves at understanding tickets every year, and none of that changes who should be accountable for an authorisation decision or who should talk to an angry client. Scope by that boundary and your automation will not need re-litigating each time the technology moves.
If you are weighing where automation fits in your support queue, our AI agents team scopes these builds against exactly this line. Book a free strategy call and we will sort your real ticket mix into the three groups above.
Frequently Asked Questions
Which help desk tickets should we automate first?
Password resets and account unlocks. They are high volume, highly repetitive, and have a verifiable success condition, provided you require multi-factor verification, synchronise the change with your authoritative directory, and log every reset as a security event.
Why should access requests not be automated?
Because an access request is a decision rather than an action. Answering it correctly needs role context, separation-of-duties awareness, and an accountable approver, none of which appears in the ticket. The failure is silent, since over-granted access rarely breaks anything until it matters.
Can AI handle security-related tickets?
It should recognise and escalate them quickly, which is genuinely useful, but it should not compose the response. A plausible automated reply can close a real incident as resolved, and an attacker who understands your bot can phrase requests to obtain resets or unlocks a human agent would have questioned.
How do we stop automation from mishandling upset users?
Encode it as a routing rule rather than relying on tone detection. Send reopened tickets, tickets with several exchanges, anything breaching its service target, and requests from a named escalation list straight to a person.
What metric tells us whether help desk automation is working?
Track how often it declines to answer, not just how often it resolves. A system that hands over when unsure preserves the early signals of new faults, while one that always answers scatters those signals into resolved tickets nobody reviews.
