Metrics and Measurement for Agentic ITSM Adoption

Five vendor-neutral measures for tracking agentic adoption, with calculation guidance and ServiceNow implementation notes

You cannot manage what you cannot measure. That is true of ITSM generally and acutely true of agentic ITSM, where the operating model itself changes and the traditional metrics, MTTR, ticket volume, FCR, do not fully capture what is different or how well it is working.

This section defines five measures specifically designed to track agentic adoption and improvement. Each measure has a definition, a calculation formula, a baseline reference, a target range grounded in published deployment data, and a detailed assessment of whether and how it can be measured using ServiceNow’s native capabilities.

These measures are vendor-neutral. The calculation formulas apply regardless of which ITSM platform you use. The ServiceNow implementation notes are provided because it is the most widely deployed enterprise ITSM platform and a common environment for agentic deployment.

Why Standard ITSM Metrics Are Insufficient

MTTR, FCR, and ticket volume are useful operational metrics. They measure the performance of the existing operating model. They do not measure the degree to which the operating model has changed.

Consider MTTR: an organization that deploys agents to assist analysts will likely see MTTR improve. But an organization that deploys agents to resolve incidents autonomously end-to-end will see MTTR compress for the agent-resolved category while shifting analyst time to higher-complexity incidents. MTTR alone cannot distinguish between these two very different operating models.

The five measures defined here are designed to surface the operating model difference, not just the performance difference. They measure how much of the work agents are doing, how well they are doing it, and whether humans and agents are calibrated to each other appropriately.

Measure 1: Autonomous Resolution Rate (ARR)

Definition: The percentage of tickets resolved end-to-end by agents without any human intervention at any step of the resolution lifecycle, from detection or intake through closure.

Formula:

$R_a = \dfrac{T_{ar}}{T_t} x 100$

where

• $R_a$ = rate of autonomous resolution (ARR)
• $I_{ar}$ = incident count of those resolved by agents
• $I_t$ = total incident count

A ticket qualifies as autonomously resolved only if no human analyst performed any action on the ticket between opening and closure. Agent-assisted resolution, where an agent performed steps but a human also acted, does not count toward ARR.

What this measures: The degree to which the Tier 1 and Tier 2 operating model has shifted from human-executed to agent-executed resolution. This is the primary adoption signal for agentic ITSM programs.

Baseline reference: Organizations without agentic deployment typically have an ARR near zero, as automation handles steps but humans perform resolution. Early agentic deployments report autonomous resolution rates of 60 to 80 percent for Tier 1 incident and service request categories (Kore.ai, 2026).

Target range: For organizations in Horizon 3 maturity (Agentic Operations) across Tier 1 incident and service request domains, an ARR of 70 to 85 percent is achievable. Overall ARR across all ticket types, including complex incidents and major changes, will be lower and should reflect the appropriate autonomy boundaries for each category.

Disaggregate by category. An overall ARR is a summary metric. The actionable insight comes from ARR by ticket category, which shows where agents are performing well, where the resolution library needs improvement, and where the autonomy envelope should be expanded or contracted.

ServiceNow Implementation:

ServiceNow’s Performance Analytics module provides the foundation for ARR measurement. The Now Assist Analytics dashboard (available from ServiceNow Yokohama release onward) includes out-of-box indicators for agent task completion. The relevant fields:

• The closed_by field on incident and request records captures whether closure was performed by a human user or by an agent identity. Agent identities must be configured with clearly distinguishable account identifiers to enable this distinction.
• The sys_created_by and opened_by fields capture ticket origin. Agent-detected tickets should be distinguishable from user-submitted tickets.
• Custom Performance Analytics indicators can be built to calculate the ratio of agent-closed tickets to total closed tickets, filtered by assignment group, category, and time period.
• The AI Agent Analytics dashboard tracks “Percentage of tasks closed using AI Agents” as a native indicator (ServiceNow Community, 2026). This is the closest out-of-box analog to ARR and can be extended with category filters.

For full ARR measurement, organizations should configure distinct agent user accounts in ServiceNow, map all agent-executed closures to those accounts, and build a Performance Analytics indicator that calculates the agent-closure ratio by ticket category.

Measure 2: Agent-Assisted Mean Time to Resolution (A-MTTR)

Definition: The mean time to resolution for tickets where agents participated in any step of the resolution process, compared against the baseline MTTR for human-only resolution of the same ticket categories.

Formula:

$MTTR_a = \dfrac{1}{n} \sum_{i=1}^{n} R_i$

where

• $MTTR_a$ = Agent-Assisted MTTR (Mean Time to Resolution)
• $n$ = Number of incidents flagged as agent-assisted
• $R_i$ = Resolution time of the $i$-th incident flagged as agent-assisted
• $\sum_{i=1}^{n} R_i$ = Sum of resolution times across all incidents flagged as agent-assisted

The comparison baseline must control for ticket category and complexity. Comparing $MTTR_a$$ for simple password reset tickets against human MTTR for complex infrastructure incidents produces a meaningless comparison. Category-controlled comparison is the requirement.

From that we can compute the comparative improvement in MTTR times as

$\Delta MTTR = \dfrac{MTTR_{baseline} - MTTR_a}{(MTTR_{baseline})} x 100$

where

• $\Delta MTTR$ = Agent-Assisted MTTR (Mean Time to Resolution)
• $MTTR_{baseline}$ = Baseline MTTR
• $MTTR_a$ = Agent-Assisted MTTR

What this measures: The efficiency gain from agent participation in resolution, expressed as a time improvement over the human-only baseline. This measure captures value from both fully autonomous resolution and agent-assisted resolution.

Baseline reference: Organizations in early agentic deployment typically see A-MTTR reductions of 50 to 70 percent for Tier 1 categories compared to human-only baseline in those same categories (Kolagani, 2024; Kore.ai, 2026). The reduction is larger for categories where agents resolve fully autonomously than for categories where agents assist human resolution.

Target range: For fully autonomous Tier 1 categories, A-MTTR targets of 5 to 15 minutes are achievable, compared to human baselines of 2 to 4 hours for the same categories. This represents a 95 percent or greater reduction for the highest-performing autonomous categories.

ServiceNow Implementation:

ServiceNow calculates MTTR natively across all ticket categories. The platform records opened and resolved timestamps on every record and provides MTTR as a Performance Analytics indicator out of the box.

To calculate $MTTR_a$:

• Filter MTTR calculation to tickets where a defined agent user account performed at least one action.
• Compare this filtered MTTR against the MTTR for tickets in the same category where only human accounts performed actions.
• ServiceNow’s Performance Analytics allows this filter-and-compare analysis through custom indicator configurations.

The “Average time to close a task with AI Agent assist” indicator in the Now Assist Analytics dashboard provides a direct out-of-box measure that approximates A-MTTR for agent-assisted tickets.

Measure 3: Knowledge Automation Index (KAI)

Definition: The percentage of knowledge articles created or meaningfully updated by agents in a measurement period, expressed as a proportion of all knowledge articles created or updated in that period.

Formula:

$I_{ka} = \dfrac{A_a}{A_t} \times 100$

where

• $I_{ka}$ = Knowledge Automation Index (%)
• $A_a$ = Knowledge articles created or updated by agents
• $A_t$ = Total knowledge articles created or updated

A knowledge article counts as agent-created if an agent generated the initial draft, even if a human subsequently reviewed and approved it. An article counts as agent-updated if an agent generated the update, regardless of human review. This definition reflects the fact that the labor-intensive step, generating the content, is agent-performed.

What this measures: The degree to which knowledge management has shifted from a manual, effort-dependent activity to an automated byproduct of resolution activity. KAI is the leading indicator for whether the knowledge base will improve or degrade over time. A KAI above 60 percent typically means the knowledge base is growing and improving faster than it is decaying from staleness.

Baseline reference: In organizations without agentic knowledge generation, KAI is near zero, as almost all article creation requires manual analyst effort. In organizations with mature agentic knowledge management, KAI of 70 to 90 percent is reported for high-volume incident and request categories.

Target range: For organizations with agent-assisted knowledge generation deployed, a KAI of 60 to 80 percent is a reasonable target within 12 months of deployment. Higher is generally better, provided that human review processes maintain article quality.

ServiceNow Implementation:

ServiceNow Knowledge Management tracks the sys_created_by and sys_updated_by fields on knowledge article records. Agent identities that generate article drafts should be configured with clearly distinguishable account identifiers.

Custom Performance Analytics indicators can calculate the ratio of agent-authored articles to total articles by filtering on agent account identities in the author field. The Now Assist for Knowledge Management capability (available in recent ServiceNow releases) tracks AI-assisted article generation natively and surfaces article creation volume by origin (AI-generated vs. manually authored) in the Now Assist Analytics dashboard.

Organizations should configure article approval workflows that route agent-generated drafts through a human review step before publication, and track both the volume of agent-generated drafts and the approval rate (the percentage of drafts approved without major revision) as quality indicators alongside KAI.

Measure 4: Agentic Deflection Rate (ADR)

Definition: The percentage of potential tickets that never became tickets because an agent detected and resolved the underlying condition proactively, before a user was affected or filed a request.

Formula:

$R_{AD} = \dfrac{I_{deflected}}{I_{deflected} + I_{submitted}} \times 100$

where

• $R_{AD}$ = Agentic Deflection Rate (%)
• $I_{deflected}$ = Incidents deflected by proactive agent action
• $I_{submitted}$ = Incidents submitted in total

This is the most difficult of the five measures to calculate precisely, because the numerator represents events that did not happen. Proactive agent action must be instrumented to generate records when it resolves a condition that would otherwise have become a ticket. Without that instrumentation, the measure cannot be calculated.

What this measures: The value of Horizon 3 operating mode, where agents prevent incidents rather than resolving them after they occur. This is the measure that most clearly distinguishes Agentic Operations from Proactive Operations: proactive operations reduce failure frequency through better monitoring and process discipline; agentic operations prevent specific incidents by detecting and resolving precursor conditions autonomously.

Baseline reference: ADR is effectively zero in organizations without proactive agentic detection. In mature deployments with AIOps integration and proactive incident prevention, deflection of 30 to 40 percent of what would otherwise be Tier 1 incidents is reported (Kore.ai, 2026).

Target range: For organizations deploying agents with integrated AIOps and proactive monitoring, an ADR of 25 to 40 percent for preventable incident categories within 18 months of deployment is a reasonable target.

Instrumentation requirement: ADR measurement requires that proactive agent actions be logged as resolution events even when no ticket is opened. Agents should generate a record when they detect and resolve a condition proactively, capturing: the condition detected, the action taken, the system affected, and a classification of the estimated ticket category that would have resulted. This record set is the numerator in the ADR calculation.

ServiceNow Implementation:

As of this writingm, ServiceNow does not have a native out-of-box ADR measure because it tracks what happens within the platform, not what does not happen. However, proactive agent actions can be captured in ServiceNow through:

• Creating a custom “Proactive Resolution” record type that agents populate when they resolve a condition before it generates a user-reported incident.
• Using Event Management records as the capture point for proactive agent resolutions when the trigger is an AIOps signal.
• Building a Performance Analytics indicator that calculates the ratio of Proactive Resolution records to (Proactive Resolution records + Incident records) for the same category and time period.

The AIOps integration in ServiceNow’s IT Operations Management module captures events that resolve without generating incidents. With appropriate logging configuration, this event data can serve as the numerator for ADR calculation.

Measure 5: Human Override Rate (HOR)

Definition: The percentage of agent-initiated actions in a measurement period that were countermanded, reversed, or overridden by a human reviewer before or after execution.

Formula:

$H = \dfrac{N_o}{N_t} \times 100$

where

• $H$ = Human Override Rate (%)
• $N_o$ = Number of agent actions overridden by humans
• $N_t$ = Total number of agent actions initiated

An override is any human action that reverses or prevents an agent-initiated action: rejecting an agent-proposed change before execution, reversing an agent action after execution, or manually escalating a ticket that an agent classified as resolved.

What this measures: Agent accuracy and organizational trust calibration. HOR is a dual-purpose measure. A high HOR indicates that agents are making decisions outside their competence boundary, or that their confidence thresholds are set too low and they are acting on insufficient evidence. A very low HOR may indicate that agents are operating within too narrow an autonomy envelope, or that human reviewers are not exercising appropriate oversight.

The target is not zero. Some level of human override is evidence of a functioning governance model. The question is whether the override rate is declining over time (indicating improving agent accuracy) and whether overrides cluster in specific categories (indicating specific calibration problems).

Baseline reference: In initial agentic deployments, HOR of 10 to 20 percent for Tier 1 categories is common and acceptable. As the resolution library matures and confidence thresholds are calibrated, HOR in well-defined categories should decline to 2 to 5 percent.

Target range: For mature agentic deployments with well-calibrated autonomy boundaries, a steady-state HOR of 3 to 8 percent indicates agents operating accurately within appropriate boundaries with functional human oversight.

Use HOR as a diagnostic, not just a KPI. Every override should be examined: why did the human override the agent? Was the agent’s action incorrect? Was the action correct but the human reviewer didn’t trust it? Was the override a false positive, where the agent was right but the reviewer disagreed? This analysis is the primary input for improving agent calibration and expanding the autonomy envelope with confidence.

ServiceNow Implementation:

ServiceNow supports HOR measurement through several mechanisms:

• The AI Control Tower (available in the Yokohama release and later) provides governance and monitoring across all agent activity, including the ability to pause, override, or deprecate agent actions. Override events in the Control Tower generate audit log entries that can be used as the numerator in HOR calculation.
• Manual escalation of agent-resolved tickets by human analysts can be captured through a custom “Escalated from Agent” field on incident records, triggered when a closed ticket is reopened by a human reviewer.
• The Agentic Evaluations capability in AI Agent Studio generates success scores by agent and by task category. Low scores in specific categories correlate with higher HOR in those categories and indicate calibration problems.

Custom Performance Analytics indicators built on the Control Tower audit log can calculate HOR by agent identity, by ticket category, and over time, enabling the trend analysis that makes HOR a useful diagnostic tool.

Measurement Program Design

These five measures work together as a measurement program, not as five independent data points.

A program with high ARR and low A-MTTR improvement may indicate that agents are resolving the right volume but are not resolving quickly. A high ARR with high HOR indicates volume but poor accuracy. A low ADR despite mature incident resolution agents suggests that proactive monitoring integration is incomplete. A declining KAI despite stable ARR suggests that the knowledge base is not being updated as resolution patterns change.

Track all five measures from the beginning of agentic deployment. Establish baselines, set targets with defined timeframes, and review monthly. The combination of all five provides a complete picture of where the agentic program is delivering and where it needs attention.

References

Kore.ai. (2026). Agentic AI in ITSM: Benefits, Use Cases, and Challenges. Kore.ai Blog.

Kolagani, S. H. D. (2024). Agentic Automation and Work Flow Orchestration in Enterprise SaaS: Effects on Ticket Resolution Time and Employee Productivity in IT Service Management. International Journal of Science and Advanced Technology (IJSAT), 15(4).

ServiceNow Community. (2026). A Field Guide to Evaluating, Analyzing, and Debugging AI Agents on ServiceNow. ServiceNow Community Engineering Blog.

ServiceNow Community. (2026). Build Better Now Assist Dashboards. ServiceNow Community AI Platform Blog.

ServiceNow Community. (2025). Measuring Success with ServiceNow: Key Metrics, Reporting Strategies, and Value Measurement. ServiceNow Community.