43,676 ServiceNow tickets analyzed: what to automate first

IT automation planned by instinct often starts with the most visible problem. Ticket data reveals something different: which cases actually occur frequently, where routine work waits, how often cases move between teams, and which knowledge is missing in day-to-day support.

For a European manufacturing group, nara analyzed an anonymized ServiceNow history from the period between 2020 and 2026. The dataset covered 43,676 incidents from six years, including 194,000 comments and 33,700 attachments. The goal was not a generic automation rate but a defensible priority order for concrete support processes.

The complete public summary is available in the ticket archive case study. This article puts the findings into context and explains how the method can be applied to other ticket histories.

The main findings

The analysis derived 51 recurring use cases from the dataset. The ten most frequent represented 48% of total ticket volume. Median resolution time across the analyzed history was 1.24 days. About 20% of tickets were reassigned two or more times.

Four numbers summarize the result:

• 43,676 incidents: the analyzed ServiceNow history.
• 51 recurring use cases: patterns grouped from similar issues and workflows.
• 48% of volume: the share represented by the ten most frequent use cases.
• Roughly one in five tickets: reassigned two or more times.

These figures describe this specific anonymized dataset. They are not a benchmark for every company and do not prove that any particular share can be resolved fully automatically.

Which patterns moved to the top of the roadmap

The analysis exposed several familiar service desk cases: password resets, SAP access and permissions, joiners and leavers, and approvals for directory rights. VPN, printers, and standard software were also among the recurring topics in the analyzed history.

Password resets

Password resets had a median runtime of one and a half hours. The actual technical action may be short, while identity checks, questions, queue time, and documentation extend the case.

A controlled agent flow can verify the user, call an approved reset tool, confirm the result, and document the ticket. Protected accounts, uncertain identity, or technical failures go to people.

Access and permissions

For SAP access and directory rights, tool execution is only one part of the process. Role, required access, justification, and the accountable approver need to be complete first.

The agent can collect this information, check rules, and prepare a decision-ready request. The authorization decision stays with an accountable person. Only after approval is the change executed through an allowed tool.

Joiner-mover-leaver

Joiners, movers, and leavers connect accounts, rights, devices, software, and several owners. That is why they benefit from a visible flow: what is complete, which approval is missing, and which step depends on another?

Automation helps with coordination and evidence. Personnel decisions and exceptional rights remain outside the agent's responsibility.

VPN, printers, and standard software

These topics are not automatic candidates by default. They become useful when known failure patterns, defined checks, and safe tools are available. An agent can inspect state, services, or certificates and document the result. Unknown configurations and hardware failures still require the team.

Our article on ten early service desk processes provides a practical way to assess these candidates.

Long cycle time is not the same as long work

A median resolution time of 1.24 days does not mean that someone actively worked on every ticket for more than a day. A case may wait in a queue, depend on missing details, or be reassigned several times. That is why cycle time becomes more useful when combined with handoffs.

A frequent, rule-based case with little active work but a long wait may be a strong candidate. A rare case with the same cycle time and high professional uncertainty may not be.

At minimum, prioritization should consider these signals together:

1. Frequency of the pattern.
2. Median and outlier cycle times.
3. Number of reassignments and teams involved.
4. Completeness of intake data.
5. Available and current resolution knowledge.
6. Required systems, tools, and approvals.
7. Clarity of the success criterion.

Test the knowledge base against real demand

The project also compared 85 existing knowledge articles with actual ticket demand. For the largest gaps, nara generated 20 article drafts for team review and approval.

This changes the perspective on knowledge. A knowledge base is not complete merely because it contains many documents. What matters is whether it covers frequent real questions and failure patterns. Ticket data identifies topics that occur often but are documented poorly or not at all.

nara Memory structures knowledge as schemas, objects, and relations and makes it usable by agents during a case. New article drafts do not become correct automatically. The team reviews and approves them before they join the knowledge base. The page on operational knowledge explains this model.

From raw data to an automation roadmap

A defensible analysis can be broken into six steps:

1. Define the dataset

Specify the period, ticket types, languages, tenants, and excluded data. Otherwise, cases that should not be compared become mixed together.

2. Extract the actual content

Do not look only at category and short description. Comments and attachments often contain diagnosis, follow-up questions, and the real resolution path. The analyzed dataset therefore included 194,000 comments and 33,700 attachments.

3. Group recurring patterns

Similar wording does not automatically mean the same process. Cases should be grouped when they share a comparable objective, required knowledge, system access, and completion criterion.

4. Combine volume and friction

Frequency alone may prioritize very simple read requests. Cycle time and reassignments add evidence about where a standardized flow could reduce waiting and handoffs.

5. Check feasibility and risk

Each candidate needs knowledge, integrations, tool permissions, approvals, and escalation paths. The nara AI automation platform connects these building blocks; the actions possible in a specific stack are validated individually.

6. Start with a bounded flow

A pilot needs clear inputs, allowed tools, success criteria, and stop signals. Only results from real operation show whether the scope should be expanded.

What the analysis does not claim

The 48% of volume represented by the ten most frequent use cases is not a 48% automation rate. The median resolution time of 1.24 days is not 1.24 days of active labor. The 20 article drafts are not automatically approved knowledge. And a roadmap is not evidence of realized savings.

These boundaries do not weaken the analysis. They make it more useful by separating observed data from the technical and organizational validation that follows.

Tickets are the starting point, not the endpoint

Ticket history shows where demand forms and friction repeats. The next step is a controlled process that connects knowledge, tools, approvals, and people. The IT service desk automation page shows how nara models cases from triage through ticket documentation.

If you want to examine patterns in your own ticket history, you can request a demo and ticket analysis. We assess the data in your context instead of applying someone else's rates to your service desk.