Which IT Tickets Can Be Automated First

Ask any IT manager what their team spent the most time on last week and you'll hear some version of the same answer: password resets, MFA issues, account unlocks, VPN problems, and software access requests. Maybe onboarding a few new hires. Maybe chasing down a compliance report.

These are not complex problems. They are repetitive problems, and repetition is exactly what software is for.

The data on how much of the queue they take up is consistent. Password resets alone are 20–50% of service-desk volume (Gartner). In Fixify's 2026 IT Help Desk Benchmark of 50,000 tickets, identity and access management plus onboarding and offboarding made up about a third of all tickets. The question isn't whether your team is doing automatable work. They almost certainly are. The question is which work to automate first, and why it hasn't been automated yet.

The anatomy of a Tier-1 queue

Across IT environments, the top ticket categories are remarkably consistent:

• Identity and access: Password resets, MFA re-enrollment, account unlocks, conditional access exceptions, group membership changes, guest user provisioning
• Lifecycle management: New hire provisioning, offboarding, license assignment, Jira/ServiceNow access requests
• Endpoint issues: VPN connectivity, Wi-Fi configuration, Outlook/Teams cache problems, Intune compliance failures, device enrollment
• Software and access: Application permissions, SSO configuration, license activation
• Everything else: The genuinely novel problems that actually require an engineer

The first two categories are the roughly one third of volume that the benchmark above measures. That last bucket, the genuinely hard stuff, is where your L2 and L3 engineers should be spending their time. Instead, most are buried in the first four categories, fielding tickets that follow the same decision tree every single time.

What "automatable" actually means

When we say a ticket is automatable, we mean three things are true:

1. The intent is classifiable. A well-trained language model can reliably identify what the user needs from their natural-language description with high confidence, and anything it is unsure about goes to a person.
2. The resolution is deterministic. Once you know the intent, the fix is a defined sequence of API calls: reset Okta TOTP factor, push Intune VPN profile, assign M365 license. There's no judgment required.
3. The risk is bounded. The action can be executed with pre-checks, validated, and rolled back if something goes wrong. It doesn't require touching production databases or making irreversible decisions.

Identity and access tickets score high on all three criteria. They're the lowest-hanging fruit in any IT automation initiative.

So why hasn't it been automated?

The blockers are rarely technical. They're organizational and architectural.

Blocker 1: The integration problem

Automating a password reset sounds simple until you realize it requires touching Okta, writing back to ServiceNow, notifying the user in Slack, and logging to your SIEM, all in one atomic workflow. Most teams don't have a unified orchestration layer that spans their stack. They have tools that don't talk to each other.

Blocker 2: The trust problem

IT teams are rightly cautious about automation touching production identity systems. "What if the AI does something wrong?" is a legitimate concern. But it's a solvable one, with human-in-the-loop controls, simulation passes before execution, and tamper-evident audit logs. The issue is that most teams haven't been shown what safe automation looks like.

Blocker 3: The prioritization problem

Building automation takes time, and the queue never stops. The engineers who would build the automation are the same ones handling the tickets. It's a classic "too busy chopping wood to sharpen the axe" situation.

Blocker 4: The maintenance fear

Teams that have tried to build automation in-house often got burned by brittle scripts that broke every time a vendor changed an API. The lesson they took away was "automation is fragile." The real lesson was "DIY automation without proper runbook management is fragile."

What changes when you automate

The math is simple enough to run on your own numbers. Here is a worked example, with assumptions you should replace with yours: a 500-person company at 3 tickets per employee per month sees 1,500 tickets. If about a third of them are identity and access work, that's 500 tickets. At 20–35 minutes of engineer time each, from receipt to close, that slice alone is roughly 165–290 hours a month. A runbook executes the same fix in ~52 seconds (tested), once a person approves it.

But the second-order effects matter more:

• Employees stop waiting in the queue. A locked-out employee waits for one approval and a runbook, not for an engineer to work down the queue to their ticket.
• L2/L3 engineers get their focus back. When the queue stops demanding constant attention, engineers can work on the infrastructure improvements, security hardening, and strategic projects they've been deferring for years.
• Compliance posture improves. Every automated action writes a tamper-evident audit record. You stop relying on engineers to manually document what they did and when.
• Toil stops compounding. Headcount growth no longer has to mean linear growth in engineer time spent on tickets.

The right way to start

Start with observe mode. Don't automate anything on day one. Let the system watch your incoming tickets for a week, classify them, and show you what it would have done. Review the recommendations. Build confidence in the classification accuracy. Then enable human-in-the-loop for your top three ticket types, where the AI stages the fix and a human approves it with one click before anything touches production.

From there, add ticket types one at a time as your team's confidence grows. Every action still waits for a named human approver.

Identity and access work is the place to start, not the place to stop. Measure your own queue, automate the third that follows the same decision tree every time, and let your data decide what comes next.