Most of the stats you hear about help desk automation focus on volume, more specifically numbers like tickets deflected, hours saved, or headcount avoided. But I want to show you a different number, and it’s not even from our industry.
Back in 1993, there was a study where operators watched over an automated system that was right about 88% of the time. The failures happened at a steady, predictable pace, but the operators only caught about a third of them. Then a second group monitored a system where the reliability fluctuated. They caught almost every failure. The only difference was consistency. It turns out steady automation is exactly what makes people miss the mistakes.
This study has held up pretty nicely for more than thirty years. A follow-up study found that experience and practice don't fix it, meaning complacency isn't a flaw in your team's character that you can train out, but what attention does when a system behaves itself for long enough.
Why I started this post with aviation psychology is because it flips the typical automation roadmap on its head. Reliability isn't just a benefit you pile up; past a certain point, it becomes the reason that your team stops double-checking. In fact, according to psychologist Lisanne Bainbridge ”the better the automation, the less practice the human gets, and the worse they perform when things finally fail.” She was talking about control rooms, but she might as well have been talking about your ticket queue.
Anyway, every roadmap kicks off by asking, "What should we automate first?" I don't think that's the right place to start. I think the real question is what should never be automated, and the answer to that makes everything else fall into place.
How should you sort tickets for automation?
It comes down to two questions: What happens if this goes wrong, and can you undo it?
That leaves you with two groups; a boring segment, where a mistake costs almost nothing and is easy to reverse, and the "loaded" segment, where being wrong costs your org trust, money, or worse a chat with Legal, and fixing it is either a nightmare or impossible.
Notice that "difficulty" isn't part of the test. That's by design. Just to clarify, "automate the boring stuff" might sound like generic advice, but "boring" here doesn't just mean tedious; it mainly means it's cheap to be wrong. Some tedious tasks are actually high-risk, and some of the easiest tasks in your queue can be a total catastrophe if they go sideways.
What belongs in the boring segment?
Here's a quick, not exhaustive list of tasks that belong in the should automate segment.
Password resets and account unlocks, where the blast radius of an error is one temporarily annoyed employee.
Access requests that have a defined approver. This is not a judgment problem, it's a routing problem.
Status lookups, where the answer already lives in a system of record and the automation is just fetching it.
Knowledge answers, where the best outcome is no ticket at all. Worth knowing that around 40% of people who submit a ticket already tried to self-serve first, so the knowledge existed and the finding didn't.
You may notice that for all these tasks, the decision/rules have already been made by whoever wrote the policy, and the automation is just executing it. A test I like is to figure out whether a competent new hire could handle the request correctly in their first week, from the documentation alone. If the honest answer is anything other than yes, then it doesn't go in this segment, no matter how often it comes in.
What belongs in the loaded segment?
Let's start with the stuff where the word "undo" doesn't even exist.
Remote wipes: A mistake here is irreversible and requires strict workflow ordering (e.g., pulling recovery keys before erasing).
Privileged access and admin-tier resets: These are high-security targets where identity verification must be hard-coded to prevent incidents.
MFA resets: Clearing authenticators removes the primary proof of identity, making it more critical than a standard password reset.
Offboarding: This involves a cascade of events across SaaS and IdP systems where errors can lead to locking out active employees.
Security incidents, HR-adjacent requests, and emotionally charged issues: These require human triage, empathy, and judgment rather than automated logistics.
Ambiguous troubleshooting: Complex issues with incomplete information are prone to "confident wrongness" in automation.
All of the tasks mentioned above aren't "loaded" because they're difficult (some are actually quite simple), they're loaded because a mistake is unrecoverable, or because the person on the other end just needs to talk to a human.
What about other tasks?
Everything that doesn't fit into those two buckets is the middle ground, and that's most of the work your IT team will handle such as multi-step provisioning or HRIS updates.
But one of the mistakes I see a lot of automation roadmaps make here is treating these as binary. You don't have to automate a whole request type to automate most of the work inside it.
For example, nobody sensible fully automates onboarding, but the intake, the checklist generation, the account creation across the systems that are stable, the audit trail proving it happened, can all be automated. This way you can still deploy automation while leaving decisions in the hands of humans.
A good rule of thumb is to put a human confirmation on every "write" action, then relax the rules once things stay boring for a while. There are two reasons for this. First, the thing that triggers a severe incident is usually trivial. Some of you will have felt this in Jamf, where a Smart Group with no criteria matches every device you own ( if you want to read up more on this, there’s a Jamf Nation thread where an admin found this out by using an empty group as an exclusion and watching software land on the whole fleet.)
Second, don't let the model decide when to ask you. Microsoft's own documentation on human supervision says that the model might not request a pause in every situation where a person would want one, and it might request pauses that aren't needed. The best practice would be to gate by request type, in configuration, not by the agent's judgment about its own risk. And confirmation on writes is not a default in anything I could find. In every major product, somebody has to switch it on, per tool or per action. Nothing in the tooling makes you think about the cost of error, so you’ve got to bring that yourself.
How can Ravenna help you with help desk automation?
Ravenna transforms your chat tools into an autonomous service layer, moving beyond mere ticket tracking toward actual resolution. By utilizing agentic automation, it handles the repetitive, low-stakes requests that we talked about in segment one by executing actions directly across your SaaS stack without manual intervention.
While legacy ITSM tools are built to route and monitor queues, Ravenna's agents interpret your internal knowledge to fix problems in real-time within Slack or Teams. It provides the efficiency of a self-driving help desk while keeping human-in-the-loop safeguards active for the high-risk "loaded" tasks. Essentially, it shifts your team's role from manually clicking through queues to architecting the automation that handles the grunt work for them.
If you want to see this in action, schedule a call with our team today.
Frequently Asked Questions
What impact does automation have on a service desk?
On the requests where being wrong is cheap, it removes handling time and the queue gets shorter. On the requests where being wrong is expensive, it moves your risk rather than removing it. The second effect is slower to show up, because a system that behaves itself for months is the exact condition that stops your team from checking its work. Sort by cost of error first and you get the volume win without the complacency that comes with it.
How do you automate a service desk?
List every request type, then score each one on two questions: what does a wrong action cost, and can you reverse it. Automate the cheap and reversible group end to end, with nobody in the path. Everything in the middle gets a human confirmation on writes, and the irreversible group waits for months of clean logs on the gated version.
How can I automate password reset requests?
Password resets are the clearest candidate in your queue. The policy is already written, the answer lives in a system of record, and an error annoys one employee for two minutes. Self service reset through your identity provider covers most of the volume, and an agent in Slack or Teams can handle verification and fire the trigger so nobody opens a portal. MFA resets are a separate request and belong in the loaded segment, because clearing authenticators removes the proof of identity a password reset relies on.
What is human in the loop automation?
A person confirms a step before the automation completes it. In a help desk that means confirmation on writes, deletes and anything privileged, while reads and status lookups run untouched. Gate it by request type in your configuration, not by the agent's own read on how risky a task is. Microsoft's documentation on human supervision is blunt about that: the model may skip a pause a person would have wanted, and ask for one nobody needed.
How do you measure the ROI of help desk automation?
Deflection rate and hours saved are the easy half, and every vendor will help you count them. The half nobody tracks is reversal: how many automated actions had to be undone, and what the cleanup took. Report the two side by side, because a program that saves hundreds of hours and deactivates one working employee will not read as a win outside IT.
