Modern ITSM platforms now ship with AI capabilities built in, letting IT teams turn on ticket classification, auto-routing, and virtual agents with little more than a license upgrade. That ease of access creates a dangerous assumption: that flipping the switch alone will improve outcomes, even in an environment cluttered with messy data and undefined processes. Real value from AI in IT operations only comes when organizations resist the urge to skip straight to deployment and instead build a structured foundation first.
This article breaks down four sequential phases, from targeting the right tickets to overhauling performance metrics, that show how to scale automation safely and effectively.
Phase 1: Target High-Volume, Low-Complexity Tickets First
Service desks used to judge themselves by how fast agents closed tickets, relying on measures like average handle time or first-contact resolution. That standard has shifted. The metric that matters now is ticket deflection: the share of tickets resolved without any human stepping in. AI agents only earn their keep when two conditions line up at once: high ticket volume and high execution accuracy.
Look at almost any enterprise service desk and a familiar pattern emerges. Password resets, access requests, mailbox quota adjustments, VPN troubleshooting, and routine onboarding tasks together make up roughly 40 to 60 percent of all tickets. None of these are expensive to fix individually, but their sheer frequency drives up cost over time. Because they follow the same resolution path every time, they're also the safest candidates for AI to handle.
Sorting Tickets Into Two Buckets
Before automating anything, split your ticket types into two categories:
- Deflectors: Issues users can solve themselves through a GenAI self-service interface, provided the answer is stable and well-documented.
- Automators: Tickets where the fix never changes, allowing an AI agent to complete the process without human involvement.
These two categories draw on different resources. Deflectors depend on a solid knowledge base, while automators need accurate workflows and entitlement records.
Building Your Starting List
Finding your own candidates is straightforward. Pull six months of ticket history, rank by volume, and isolate the ticket types with short resolution times and consistent handling steps.
Whatever shows up on both the high-volume list and the low-complexity list is where automation should start. In a typical case, password resets and access requests are already fit for automation, while common how-to questions are better suited to GenAI self-service.
Guarding Against False Wins
Deflection rate alone doesn't tell the whole story. A ticket that gets deflected and then bounces back means the customer suffered through two poor experiences instead of one.
Keep a human reviewer available for anything the AI marks as uncertain or too risky to handle alone, and track customer satisfaction alongside deflection numbers. When satisfaction scores hold steady, you know the deflection is genuinely working rather than just hiding the problem.
Phase 2: Clean Data Across CMDB and Service Catalog
Every AI feature in your ITSM or ITOM stack depends entirely on data your organization already holds, namely ticket records, CMDB entries, and the relationships between services. AI doesn't add new intelligence to the mix; it simply executes decisions on existing data faster and at greater scale than a human team ever could.
This is why governance frameworks like COBIT insist that data quality must hit a certain maturity level before any organization hands decision-making over to automation.
Structuring the CMDB Correctly
Before rolling out AI, examine how services are actually defined in your CMDB. ITIL draws a clear line between business services, which deliver value directly to customers, and technical services, which support those business services behind the scenes.
A CMDB that labels everything simply as a "service" without mapping how business capabilities connect to underlying technical components creates a problem. Human engineers could once rely on memory to understand these relationships, but AI has no such intuition. It treats whatever sits in the CMDB as complete and accurate, errors included.
The fix is organizing service definitions into three tiers:
- Business services at the top.
- Technical services in the middle.
- Configuration items (CIs) at the bottom.
This gives every system in your stack a single, consistent hierarchy to reference.
Scoping the Cleanup
Rather than attempting to clean your entire CMDB at once, narrow the effort to the business services and CI types tied to your first AI use cases. This is where inaccurate data does the most damage and where cleanup pays off fastest.
For example, if AI-assisted major incident response is your starting point, focus only on the CIs behind your top ten business services. With that relationship data cleaned up, AI can group thousands of monitoring alerts into a single major incident record during an outage, and platforms like Freddy AI can correlate those alerts against the CMDB in real time while drafting post-incident reports automatically.
Aligning the Service Catalog
Once the CMDB hierarchy is solid, the front-end service catalog needs to match it, since this is where end users interact with ITSM and where self-service and fulfillment actually happen.
Three elements determine whether AI can succeed here:
- Catalog item structure: Accurate titles, descriptions, fields, and CMDB mapping.
- Fulfillment logic: Approval chains, resolver groups, SLAs, and automation rules.
- Request taxonomy: Clear separation between requests, incidents, problems, and changes.
Sitting down with service owners to review, retire, or merge redundant catalog entries, and tightening the language in each one, directly improves how accurately AI matches incoming tickets to the right service.
Phase 3: Embed AI Within the ITSM Data Layer
AI agents that carry a request from start to finish without any human intervention create far more value than assistant-style tools that merely support a human agent. The reason is simple: end-to-end agents pull the ticket out of the queue entirely, rather than just shaving a few minutes off someone's workload.
The Three Requirements of a Working Agent
A useful framework for judging whether an AI agent actually functions comes down to three capabilities:
- Understanding: The agent must understand what the user wants, even when the request is unclear or poorly worded.
- Context: It needs to pull relevant context from the ITSM platform, including user identity, entitlements, asset records, and past tickets.
- Action: It must take real action to resolve or advance the ticket.
Skip any one of these three steps and what you have isn't an agent, just a chatbot dressed up with extra functionality.
Three Sequential Functions
True Tier 0 resolution capability requires executing three functions in order:
- Intake and categorization: Accurately map whatever language the user types to the correct catalog item or incident model, no matter how vague the description.
- Contextual validation: Query the CMDB and IAM systems in real time to confirm hardware assets, active entitlements, access control levels, and open ticket history before any resolution path runs.
- Orchestration and fulfillment: Expose backend APIs directly to the service portal, so that once a request clears validation, the provisioning workflow triggers automatically without waiting on a human.
Setting the Benchmark
The target here is zero-touch, real-time fulfillment: a standard request should move from the moment a user types it to backend confirmation within seconds, with no dependency on a human agent's queue.
When the three layers integrate properly, two outcomes should follow:
- High deflection rates: Targeted catalog items should see a high deflection rate, meaning the large majority of requests open, validate, execute, and close entirely at Tier 0.
- Minimal queue dwell time: Context validation and orchestration should happen programmatically, cutting resolution time down to roughly the runtime of the API call itself.
If a request still waits on an email confirmation or gets routed to a queue for manual approval, the benchmark hasn't been reached.
Conclusion
Getting real value from AI for IT operations isn't about flipping a switch and hoping for the best. It requires building a deliberate foundation: identifying which tickets are actually suited for automation, cleaning up the CMDB and service catalog so AI has accurate data to act on, embedding agents deep enough into the ITSM stack that they can understand, contextualize, and act without human hand-holding, and finally rethinking how you measure human performance once the easy tickets disappear from the queue.
Done properly, this shift doesn't just reduce ticket volume; it changes what your human analysts actually do all day. Instead of grinding through repetitive, low-value requests, Tier 1 and Tier 2 teams shift toward reviewing failed automations, refining escalation logic, and feeding what they learn back into the system. That feedback loop is what turns a one-time automation project into a system that keeps improving itself.
Freshservice is built around this exact handoff between automation and human judgment. Freddy AI Agent Studio handles autonomous resolution for the predictable, high-volume work, while Copilot Resolution Insights gives human analysts real-time context and root-cause analysis the moment an escalation lands in their queue. Together, these capabilities support the kind of structured, data-driven automation that actually holds up at scale, rather than automation that looks good in a demo but falls apart in a messy environment.
Top comments (0)