Most of the stats you hear about help desk automation focus on volume, specifically tickets deflected, hours saved, or headcount avoided. I want to show you a different number, and it actually comes from outside 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 is Parasuraman, Molloy and Singh, and it’s held up for thirty years. The follow-up literature (Parasuraman and Manzey, 2010) found that experience and practice don’t fix it. Complacency isn’t a flaw in your team’s character that you can train out. It’s just what attention does when a system behaves itself for long enough.
The reason I’m starting a help desk 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’s the reason your team stops double-checking. Lisanne Bainbridge pointed this out: 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.
What should you actually be sorting by?
It comes down to two questions: What happens if this goes wrong, and can you undo it?
That leaves you with two groups. First, the “boring” segment, where a mistake costs almost nothing and is easy to reverse. Then there’s the “loaded” segment, where being wrong costs you trust, money, or 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. “Automate the boring stuff” sounds like standard advice, but “boring” here doesn’t just mean tedious; it 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?
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.
The thing these have in common is that the decision was already made by whoever wrote the policy, and the automation is just executing it. A test I like is whether a competent new hire could handle the request correctly in their first week, from the documentation alone. If the honest answer is, “well, they’d also need to know that Sandra in Finance prefers…” then it doesn’t go in this segment, no matter how often it comes in. That preference lives in Sandra’s head. Automating around context that only exists in people’s heads is how you end up with a system that’s right 88% of the time, and you saw how that goes.
What belongs in the loaded segment?
Let’s start with the stuff where the word “undo” doesn’t even exist.
A remote wipe takes a laptop back to factory state and there is no version of that you get back. And the order inside the workflow matters more than the workflow does. You pull the FileVault recovery key before you fire the erase, not after, because afterwards there’s nothing left to pull it from. An agent that can run those two steps can also run them in the wrong order, and it will do it confidently. So automate the intake, the device lookup, the compliance check, the audit trail, and put a named human on the trigger.
Privileged access and admin-tier resets are next. This is where being wrong becomes a security incident, and it’s not hypothetical. The help desk reset path is a documented attack route, which is why the CISA and FBI advisory on Scattered Spider tells organizations, in plain terms, to verify identity before resetting passwords or adding MFA devices. A standard employee reset can run on a confirmation after a push verification. A privileged reset should never auto-execute. I’d rather hard-code that than leave it in a policy doc nobody reads.
MFA resets sit here too, because clearing somebody’s authenticators removes the thing that proves they’re them. Bigger deal than a password.
Offboarding is the cascade problem. One termination event touches the IdP, every SaaS entitlement, and the device, and the failure mode isn’t a stalled ticket, it’s locking out someone who still works there. Microsoft ships a deletion threshold for its provisioning service that quarantines the job and emails you when too many accounts are about to go at once. Nobody builds a circuit breaker for a hypothetical. Microsoft looked at what happens at scale and built one.
Then the rest, more briefly. Security incidents, where you automate triage and containment but never the call on what the incident means. Anything HR-adjacent that lands in your queue, which needs routing to a person fast, not an answer. Emotionally charged anything, because automation can handle the logistics around those moments but not the content. And ambiguous troubleshooting, the “it’s slow sometimes, only on Thursdays” kind, which needs hypothesis generation from incomplete information, which is exactly where confident wrongness lives.
These 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 everything in the middle?
Everything that doesn’t fit into those two buckets is the middle ground, and honestly, that’s most of your work. Think multi-step provisioning or HRIS updates.
The mistake is treating these as binary. You don’t have to automate a whole request type to automate most of the work inside it. 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, that’s assembly line work. The judgment lives at the edges. Automate the line, keep the edges human.
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 the nightmare scenario is usually trivial. Some of you will have felt this in Jamf, where a Smart Group with no criteria doesn’t match nothing, it matches every device you own. 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. A human handed a blank list stops and asks. Automation reads the blank as “all.” The confirmation step exists to close exactly this gap and it costs maybe ten seconds a run.
Second, don’t let the model decide when to ask you. Microsoft’s own documentation on human supervision says it plainly, 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. Gate by request type, in configuration, not by the agent’s judgment about its own risk. And confirmation on writes is a default in almost nothing 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 cost of error. You have to bring that yourself.
Why does the order matter more than the list?
Every automation you ship either deposits trust or withdraws it. A month of clean password resets buys the credibility to automate access requests. A quarter of clean access requests buys the plumbing to try provisioning. One visible mistake on a sensitive workflow spends all of it at once, and then some.
Gartner surveyed 5,000 employees a few years back and found that 40% would stop using an app after just one bad experience. Even worse, 42% told their coworkers about it. So the damage hits twice: the user quits, and then they tell everyone else to stay away. Your adoption curve doesn’t just flatline; it goes backward via the break room.
This is also why I’m skeptical of “deflection rate” bragging. Median AI deflection is around 22%; anything over 45% needs a very clear definition before I’ll applaud. A system that deflects by being quietly wrong is just that 1993 experiment with a different logo on it.
What should you test before you sign anything?
The behavior at the boundary. That’s what people remember, so test it first. Not the happy path. The handoff.
A good system says “this one needs a person,” says why, and puts everything it already gathered in front of the right human. A bad one makes the employee fight the bot for the right to talk to one. If your escalation path contains the phrase “please describe your issue again,” that isn’t a handoff, it’s a do-over, and everybody knows it.
So test the wrong-account reset. Test the request from someone who left last week. Test the empty-Smart-Group equivalent in whatever you’re buying. Vendors demo the 88%. You’re buying the other 12%.
So what do you do Monday morning?
First off, skip the “maturity model.” Nobody actually ships those.
Grab 90 days of tickets and sort them by volume to see the shape of your queue. Then, re-sort every category by the cost of making a mistake. The “boring” segment, ranked by volume, is your roadmap for the next six months. Start there and keep it simple. The “loaded” segment isn’t a backlog; it’s your design spec for how to hand things off to a person. The middle ground is where you tackle projects one at a time, keeping the human confirmation gates on.
And here’s the thing that should settle it. Nobody in IT sequences changes by volume. You don’t order the change calendar by how many tickets a change touches, you tier by risk and match approval authority to the tier. That discipline has been in place for 20 years and nobody argues about it.
Your automation roadmap is the last place in IT where you’re still allowed to sort by volume. Decide what you’ll never automate, and the rest of the roadmap writes itself.
If you want to see what boundary behavior looks like when somebody designed for it, we’re happy to show you ours, or you can poke around the docs first.
Frequently Asked Questions
How do I tell whether something belongs in the loaded segment?
Ask what an incorrect action costs and whether you can reverse it, not how hard the request is. If the failure mode is “somebody is mildly annoyed for two minutes,” it’s boring. If it’s “we deactivated a working employee,” it’s loaded. And some loaded requests are trivially easy to handle, which is exactly what makes them dangerous.
Isn’t “automate the boring stuff first” just sorting by difficulty with extra steps?
No, and this is where the two orderings come apart. Sorting by difficulty puts multi-system provisioning early because it’s mechanical and it demos well. Sorting by cost of error puts it in the middle with confirmation gates on, because a wrong write to your identity provider is not a two-minute undo.
Won’t confirmation gates slow everything down?
On the requests that deserve it, yes, by seconds. The boring segment, which is most of your volume, should run with zero human touch. The gates belong on writes, deletes, and anything privileged. What those seconds buy is a team that still trusts the system in month six, and that trust is the thing that decides whether any of this survives.
