AI and Automation in ITSM: What's Actually Changing, Not the Vendor Pitch
Every ITSM vendor now has an "AI" section on its pricing page. Most of what's behind it is a chatbot that can paraphrase a knowledge base article. The part that actually changes how an IT team spends its day rarely gets a slide of its own: automating the recurring, low-judgment tickets that eat hours every week, using AI to make sense of ticket data at scale, and having an API open enough to build both of those yourself if the vendor's own tools don't go far enough.
The real opportunity: automating what doesn't need a human
Quick answer
The goal isn't automating everything - it's automating the tickets that are purely repetitive: the same script, the same manual steps, the same decision, every single time, with no real technical judgment required. That work is pure overhead, and every hour it consumes is an hour your team isn't spending on the problems that actually need a person.
When a repetitive request gets automated, the effect shows up in more than one place at once. The IT staff member who used to handle it is now free for the harder problems - the ones that genuinely can't be automated, or that need someone physically present. The user who submitted the request doesn't have to wait for a free technician; they get served immediately instead of sitting in a queue. Average resolution time drops, and so does your SLA exposure. And the same headcount ends up handling a meaningfully higher volume of tickets in less time, without anyone working harder.
Getting started is easier than most teams expect
Adding automation to an ITSM system isn't the technical undertaking it sounds like. Most modern ITSM platforms already support it natively, either through built-in automation and AI features or by exposing an API that external automation tools can connect to.
If your organization already runs automation tools for other purposes - enterprise applications, an internal integration team - you're ahead of the curve. If not, the tools available today are genuinely approachable. Most of them are drag-and-drop, no-code or low-code, and don't require prior development experience. The learning material is freely available online, several vendors offer free certifications that take very little time to complete, and the return relative to the investment is hard to argue with. Tools like Workato, n8n, and Make.com are all straightforward enough that a motivated IT generalist can be productive with them in days, not months.
Recurring tickets worth automating first
This is a short sample, not an exhaustive list, but it's a good starting point for identifying what's already sitting in your queue, waiting to be automated:
Identity and access
- Password resets and unlocking a locked-out account - after identity verification, the system can perform the reset or unlock and send instructions directly to the user.
- MFA re-enrollment - verify the request, reset MFA, send a re-enrollment link.
- Adding or removing a user from a standard, pre-defined permissions group based on role, department, or system - no human decision required.
- Unlocking an account locked from repeated failed logins, when there's no indication of an actual security event.
- Resyncing an account against a directory or SaaS system after a known sync failure.
Software and licensing
- Assigning a software license, when one is available and the user meets the criteria.
- Reclaiming an inactive license after a defined period of no use, and returning it to the pool.
- Installing pre-approved software from the IT catalog, pushed automatically through an endpoint management tool.
Connectivity and known endpoint issues
- Granting VPN access when the user meets a pre-defined policy and no exception approval is needed.
- Reconnecting a network drive or printer via script or endpoint management.
- Clearing cache or restarting a local service through an agent when a known fault pattern is detected.
- Fixing a known configuration issue - resetting a registry value or reapplying a policy when the pattern is already understood.
- Resolving a known VPN fault - restarting the service, refreshing the profile, updating configuration, or silently reinstalling the client.
Everyday admin
- Creating a standard shared mailbox or distribution list, including name, owner, and members, based on the request details.
- Adding a user to a Teams, Slack, or SharePoint workspace when access is based on defined membership or a pre-approved request.
- Increasing a mailbox or storage quota according to policy, as long as the request falls within an automatable range.
- Restoring a deleted file from retention or backup, when the path and user are unambiguously identified.
- Handling an "I don't have access" ticket when the cause is predictable - the system recognizes the user is simply missing from a specific group and adds them.
Lifecycle
- Creating a new user as part of onboarding - account creation, group assignment, licensing, and permissions based on role.
- Disabling a user during offboarding - account disable, session termination, license and group removal, mailbox handling per policy.
Walkthrough: automating the classic "VPN won't connect" ticket
Take a recurring ticket like "VPN won't connect," where 80% of cases come down to the VPN service getting stuck or the local profile getting corrupted. Here's what the automation actually looks like end to end:
- The user opens a ticket, or clicks a "Fix my VPN" action directly in the self-service portal.
- The system identifies the user's machine via the CMDB or endpoint management tool.
- It runs a remote script through Intune, SCCM, an RMM tool, or similar.
- The script checks the basics: is the VPN service running, is the client installed, does the profile exist, is there connectivity.
- If the service is stuck, it restarts it. If the profile is corrupted, it deletes it and pulls down a clean one. If the configuration has drifted from baseline, it's reset. If the client itself is broken, it gets silently reinstalled.
- Finally, it runs a connectivity or health check.
If everything comes back clean, the ticket closes automatically and the user gets a notification. If it doesn't, the ticket routes to an IT staff member - along with every diagnostic result already collected, so nobody starts from zero.
Walkthrough: turning unused software licenses back into a resource
Here's a pattern almost every IT team recognizes: someone requests a license - Adobe, Power BI, a dev tool, some other SaaS product - uses it once or twice for a specific task, and then never touches it again. Without any oversight, that license can stay assigned to them for months or years, quietly costing the organization the whole time.
The automation works like this: the system pulls usage data from the licensing system or the SaaS platform itself, checks when the user last logged in, and if there's been no activity for, say, 60 days, flags the license as idle. Depending on policy, it can notify the user automatically before removal - something like: "No usage detected on this license in the last 60 days. If you still need it, confirm within 7 days." No response, no renewed usage, and the license is automatically removed and returned to the pool.
The flow, end to end: license assigned - usage monitored - 60 days of inactivity - user notified - no response or renewed use - license removed - returned to the pool.
The savings come from two directions. The first is avoiding unnecessary new purchases - if a new hire needs a license and there's already one sitting idle in the pool, you reassign it instead of buying another seat. The second is a smaller renewal bill: if the automation surfaces dozens or hundreds of unused licenses over the course of a year, the organization can actually shrink what it's paying for. Run the numbers on a $40-a-month license sitting idle across 100 users, and that's $4,000 a month - $48,000 a year - for software almost nobody is touching. And nobody on the IT team has to manually comb through usage reports, send emails, wait for replies, and revoke licenses one at a time.
It's worth being explicit about the intent here, because it's easy to get this backwards: the goal isn't to take licenses away from people. It's to make licensing a dynamic resource. A user who needs a license gets it fast, and if they stop using it, it goes back into the pool for someone else. IT ends up improving both availability and cost control at the same time.
From simple installs to full approval workflows
One of the simplest and most effective automations is installing software directly from an approved catalog. The user requests it, the system confirms it's approved and compatible with their device, triggers the install automatically, and verifies it succeeded. Only the exceptions ever reach a technician. A request that used to require manual handling becomes a genuine self-service action.
You can take this a step further and build a full workflow around the request, not just automate the install itself:
Software request - eligibility check - manager approval - security/IT approval if required - license check - automatic install - success verification - ticket closed.
That means even software that isn't eligible for instant self-service can still move through an orderly process without a technician managing it by hand. The user submits the request, and the system routes it automatically to the right approvers based on the type of software, the department, the cost, or the risk level. Once every approval clears, the workflow continues on its own and triggers the install through Intune, SCCM, Jamf, or another endpoint management tool.
You can also define different paths for different cases: free, pre-approved software installs immediately; paid software requires manager or budget-owner approval; anything security-sensitive also routes through a security approval. The advantage is that IT stops manually chasing approvals, sending reminders, or repeatedly checking whether a request has been signed off. The system manages the entire lifecycle of the request, from submission to the actual install.
Self-service and knowledge base: solving the problem before a ticket ever opens
There's a whole category of AI value in ITSM that has nothing to do with automating an action, and everything to do with an internal knowledge base built around clear, practical how-to articles: how to connect to VPN, how to set up MFA, how to install approved software, how to request access to a given system, how to fix common Outlook issues, and so on.
When a user starts typing a request in the self-service portal, the ITSM system can analyze the text in real time and surface relevant knowledge base articles before a ticket ever gets created. Someone starts typing "I can't connect to the VPN," and the system immediately shows an article like "Troubleshooting VPN Connection Issues" with a few simple self-check steps. If one of them fixes it, no ticket ever needs to open.
The flow: user starts creating a ticket - system analyzes the request - relevant KB articles are suggested - user follows the steps - issue resolved - no ticket created.
The benefit runs in both directions. The user gets a near-instant answer instead of waiting on a technician, and the IT team gets fewer repetitive tickets, freeing up time for the problems that actually require judgment.
Layering AI on top makes this meaningfully more effective, because the user no longer needs to know the name of the problem or pick the right category. They can write something in plain language like "since I changed my password I can't work from home," and the system can infer this is probably a VPN or authentication issue and surface the right article anyway.
The way I'd put the core message of this section: good self-service isn't measured by how many tickets users can open themselves - it's measured by how many tickets they never need to open at all. Pairing a service portal with an internal knowledge base means the user's actual need can be identified while they're still typing the request, and a well-timed article can resolve the issue with zero IT involvement.
It also creates a genuinely useful improvement loop: the more recurring tickets an IT team identifies, the more of those resolutions get turned into KB articles - so the next time the same issue comes up, the user may resolve it themselves before it ever becomes an incident at all.
What built-in AI in ITSM platforms can actually do today
Modern ITSM platforms increasingly ship with built-in AI aimed squarely at shortening diagnosis and resolution time. In Jira Service Management, for example, Rovo lets IT staff draw on historical tickets, knowledge base articles, and other connected sources to get a summary of an incident, surface relevant information, and get suggested next steps or resolution paths. Atlassian also offers capabilities that help turn recurring incidents into knowledge base articles and reuse that knowledge automatically the next time a similar request comes in.
The value for an IT team here is real: instead of a technician manually searching for similar past tickets, reading through the entire conversation history, and trying to track down the right article, an AI layer can pull the relevant context together and present it directly alongside the current ticket. The same kind of capability can strengthen self-service too, using the knowledge base and AI together to give the user an answer or direction before any IT staff member gets involved at all - JSM's AI and Virtual Service Agent features are built specifically for scenarios like this.
What to actually evaluate, beyond the "AI" checkbox
Just as important as what a platform's built-in AI can do is how open the system actually is to connecting outside AI tools. An organization can choose to rely entirely on the AI that ships with its ITSM platform, or connect an external model or automation tooling with controlled access to tickets, the knowledge base, and other data sources. Even Rovo itself can work with information from Atlassian's own apps as well as connected third-party sources.
So when you're evaluating an ITSM system, I wouldn't just check whether there's a checkmark next to "AI" on the feature comparison table. Look at what the built-in tools actually do, what data sources they can reach, whether you can plug in external models or automation tools, what APIs and integrations are actually available, and what the security and permission boundaries look like.
The cost model deserves the same scrutiny. In some cases a built-in AI solution will be simpler and cheaper to run; in others, connecting an external tool will be more flexible and cost-effective. Look at the total cost - licensing, AI usage, integration work, ongoing maintenance, and how it scales with user count - not just the ITSM platform's base price.
The message I'd want a reader to take from this: don't choose an ITSM system based only on the AI capabilities it has today. Check how much room it gives you to adopt the AI capabilities you're going to need tomorrow.
Where this is heading
As AI becomes a routine part of daily work everywhere else, its role inside ITSM keeps growing along with it. We're at the point where AI and automation aren't a nice-to-have bolted onto the service desk anymore - they're becoming part of how IT teams will simply have to operate in the next few years.
The IT role itself is shifting alongside this. We used to think mainly in terms of System Administrator, System Specialist, or Help Desk. Increasingly, we're seeing roles built specifically around AI, automation, and operations - AI Administrator, AI Specialist, AI Operations. IT staff now need a skill that wasn't really part of the job before: not just keeping systems running, but understanding how to weave AI tools and automation directly into existing workflows.
The reason is simple: organizations themselves are moving faster. Development cycles are shrinking, time-to-market is a real pressure, and every part of the business is expected to respond faster than it used to. A developer blocked by a missing permission, an environment issue, a pending software install, or an access request can't sit around for hours, let alone days, waiting on IT. That delay isn't just an inconvenience - it directly slows down the pace of the whole organization.
In that environment, the workflows that used to be perfectly acceptable often aren't fast enough anymore: a user opens a ticket, waits for a technician to pick it up, read it, understand it, search for a fix, perform it manually, and only then respond. Combining AI and automation inside an ITSM platform changes that model directly. AI can understand the request, classify it, pull relevant context from historical tickets and the knowledge base, and suggest a fix. Automation can carry out the action itself - in the right cases, resolving and closing the ticket with no human touch at all.
The result isn't just faster ticket handling. It's less manual work, fewer human errors, more consistent processes, and an IT team with more time available for the problems that genuinely require expertise and judgment.
That's really how I'd frame the future of ITSM: not as a system for managing tickets, but as a platform that connects users, knowledge, AI, and automation. The faster an organization moves, the more critical it becomes for IT to deliver a fast, automatic, accurate response.
Which means an organization choosing an ITSM system today shouldn't just be thinking about its needs right now - it should be thinking about how well that system can grow into a world where AI and automation are simply part of how IT operates. That shift is already underway, and it's moving fast.
Written by
Shay Rozov
Shay Rozov has 30 years of experience in IT and technology leadership, with hands-on expertise evaluating and deploying enterprise IT and AI tools.
Related in Guides
What Is ITSM? A Practical Primer for IT Managers Choosing Their First Help Desk Tool
A plain-language, practitioner-level explanation of IT Service Management - ITSM vs. ITIL, the four processes that actually matter, common rollout mistakes, and which capabilities to prioritize by team size.