What Most Teams Miss: Critical Considerations for ITSM Automation
Introduction
Utilizing valuable, skilled labor to perform tedious and repetitive tasks can be a massive drain on budgets and employee morale. A large percentage of IT tickets are purely procedural and require no complex human judgment to process. However, indiscriminately automating every task is not the answer either.
Interestingly, organizations that achieve sustainable automation success spend more time on eliminating and simplifying existing processes. Intelligent automation stems from understanding the context of each task and tailoring the steps accordingly. For example, when automating steps of an ITSM ticketing system, rather than creating a bot to parse and route "password reset" emails to the help desk, the organization should look to eliminate the ticket at the source. By implementing a self-service password reset portal that utilizes multi-factor authentication, the need for that type of ticket is eliminated. Automation is then used strictly for backend identity verification, ensuring the help desk never interacts with—or reports on—a request that does not require human intervention.
This article explores the key considerations for automating your ITSM practice, including simplifying and eliminating tasks before automating them.
Summary of ITSM automation key considerations
Consideration | Description |
|---|---|
Ensuring efficiency before automating | Eliminating unnecessary steps and simplifying processes before automating them helps you avoid speeding up flawed workflows. |
Aligning concepts before technical integration | Standardize how services, incidents, priorities, and business impact are defined across all systems before building cross-platform automation. |
Operational longevity | Building automation using abstraction layers and configuration tables allows workflows to survive organizational changes, system upgrades, and evolving business rules. |
Value-based automation prioritization | The best approach is to evaluate automation opportunities across volume, pain points, risk exposure, and strategic value (not just ticket frequency). |
Ensuring efficiency before automating
The merit of any process, including automation, is ultimately determined by how well it helps users accomplish their goals. Automated workflows can likely turn a multi-hour manual task into a sub-second operation, but it's important to first take a step back and ask whether that workflow should exist at all. This question also aligns directly with ITIL 4's emphasis on value co-creation and challenging existing practices within the "Plan" and "Improve" service value chain activities. Recently released, ITIL 5 also reinforces the principle by pushing organizations to fundamentally rethink processes rather than just make bad processes faster.
For context, consider how most organizations handle service requests. The traditional approach involves a hierarchical structure where a request must go through several layers of approval before it can be fulfilled. Automation can be used to replicate these layers, routing requests faster through multiple checkpoints, but it may still take days to fulfill because the approval process itself may be flawed.
Streamline service management with a powerful, yet easy-to-use tool
Resolve issues faster, reduce downtime, and take control of your service operations—all in one platform.
Consider leveraging ITIL4's guiding principles, particularly "Focus on Value" and "Progress iteratively with feedback," to evaluate whether a process—however fast it may become through automation—truly contributes to a desired outcome. Apply these principles by conducting value stream mapping before automation implementation.
Process legitimacy assessment before ITSM automation
A word of caution: Don't try to achieve "process perfection" before any automation begins. That's an impossible standard that prevents progress. Instead, dedicate more time to examining processes and eliminating unnecessary steps before automating the essential core that remains.
Categorize processes into three buckets before automating:
- Eliminate processes that exist due to outdated policies.
- Simplify processes with unnecessary complexity.
- Automate processes that create value but consume disproportionate effort.
Interestingly, most automation programs never reach this categorization step because practitioners have already committed to automating whatever generates the most tickets. What creates value depends entirely on the dimensions you analyze, which is why identifying the right automation opportunities requires evaluating processes across multiple lenses simultaneously.
Aligning concepts before technical integration
Of all the concepts your cross-functional teams need to align on, services are perhaps the most important in ITSM. If your CMDB, service catalog, and monitoring platform all define and integrate services differently, automation that operates across these systems will trigger inconsistent rules.
ITIL 4 distinguishes between business services (ones that deliver value to customers) and technical services (ones used to deliver business services). Unfortunately, most organizations' CMDBs and service catalogs commonly list everything as “services” without explicitly mapping the relationship between business capabilities and technical components.
To enable true unification of service definitions, consider starting with a comprehensive audit of existing terminology and classifications used across different tools and departments. When a technical service experiences problems, automation should automatically identify the affected business services and prioritize a response based on business impact.
Define a service hierarchy that clarifies relationships as shown in the table below.
Service Level | Description | Examples |
|---|---|---|
Business Services | Customer-facing capabilities that deliver business value | Email and calendar, file storage, ERP, CRM, etc. |
Supporting Services | Technical services that enable business services but aren't directly consumed by end users | Active Directory, databases, network infrastructure, backup and recovery |
Components | Individual technical elements that comprise services | Specific servers, applications, network devices, cloud resources |
Once these hierarchies are mapped in your CMDB, the automation workflow knows which components support which supporting services, and which supporting services enable which business services.
You must also catalog how each system currently defines core concepts such as incidents, service requests, priorities, and business impact levels. The standardization process requires cross-functional collaboration where teams align on a single definition for each service management concept. Use ITIL 4 guidelines as the baseline, but adapt them to fit your organization's needs and existing processes.
Establish criteria that distinguish incidents from service requests, problems, and changes based on the following definitions:
- Incident: An unplanned service degradation or unavailability that requires restoration
- Service request: A user-initiated request for information, access, or a standard service
- Problem: The underlying cause of multiple incidents
- Change: A planned modification to IT infrastructure or services
These definitions might seem obvious at first glance, but applying them in practice can be tricky. To prevent different tools from interpreting the same incident or service request with varying levels of urgency and business impact, consider standardizing priority matrices. For example, if one automated workflow assigns a "high" priority that another system interprets as "medium," subsequent automated actions (like routing to a resolver group, escalating to management, or triggering automated remediation) will inevitably conflict. You must synchronize these matrices to ensure automated actions remain consistent across your entire stack.
How priority patterns can guide your automation scope
Having a priority matrix serves operational needs by determining response speed for individual incidents. However, this same data should feed your strategic automation decisions. The two prioritization frameworks work together when you recognize that operational priority patterns reveal automation opportunities.
As shown in the illustration below, business impact levels must reflect actual organizational priorities rather than technical convenience. High impact means a service affects many users or critical business functions. Urgency refers to how quickly the issue must be resolved based on business needs.
Unified priority matrix for ITSM automation
Operationally, the matrix helps determine response speed for individual incidents. Strategically, it reveals automation opportunities. To build a similar matrix, pull incident data by priority level and categorize by type. Calculate total handling time for each category. Identify which categories drive the most P0/P1 escalations and which consume the most cumulative staff time. These insights guide where automation delivers maximum business value.
Track your P0 and P1 incidents over six months. If the same issue triggers a high-priority response repeatedly, that's a candidate for preventive automation, even if the total volume stays low. Conversely, high-volume P3 and P4 tickets justify efficiency-focused automation. Password resets are rated low priority individually, but handling 500 per month consumes significant capacity. Automating them frees your team to focus on higher-impact work without adding headcount.
Use this decision framework when building your automation roadmap:
- High-priority, low-volume incidents justify automation through risk reduction.
- High volume, low-priority requests justify automation through capacity recovery.
- High-priority, high-volume issues need both preventive and efficiency automation.
- Low-priority, low-volume work probably doesn't justify automation investment yet. This connects your daily ticket data directly to your long-term automation strategy.
Operational longevity
Tightly integrated systems and ITSM processes are both recommended, but changes in one can break automation in another. The core problem is that organizations commonly optimize automation for immediate benefits and do not see the various operational changes that may eventually happen in the workflows. When automation is built without considering future changes, it accumulates technical debt that becomes increasingly expensive to maintain and modify over time.
Sustainable automation requires a different approach entirely. Start by assessing what can actually change in your ITSM environment over time. For example:
- Service catalogs grow and shrink as offerings change.
- Support teams reorganize as business priorities shift.
- Integration points break as platforms upgrade and systems migrate.
- Business rules evolve as SLA targets and approval requirements update.
- Field names change during data quality initiatives.
- Custom fields appear and disappear as requirements evolve.
Each of these changes is a routine operational activity, yet automation built without considering these changes requires extensive retrofit each time one occurs. Every quick fix and workaround you apply adds another layer of debt that makes the next change even harder.
Consider building abstraction layers between workflows and the systems they integrate with. An abstraction layer is basically a standardized interface you put between your automation workflow (the logic) and the external systems it touches (the data and endpoints). Under this model, the ITSM workflow never references specific field names, user IDs, or system endpoints directly. Instead, it utilizes configuration tables to map logical concepts to actual implementation details.
As an alternative, use configuration tables that map logical concepts to actual implementation details. When something changes, you are required to update only the configuration table. For instance, when your incident workflow needs data from the CMDB, it shouldn't reference specific CMDB field names directly. It should call an abstraction layer, which can be a script or an integration spoke, that knows how to retrieve "asset owner" regardless of what the CMDB calls that field. When the CMDB field name changes, you can simply update the abstraction layer once. Every workflow that uses it keeps working without breaking or requiring modification. Apply this practice to all ITSM integrations, including HR systems for user data, monitoring tools for incident creation, and deployment platforms for change automation. You're essentially reducing technical debt with this approach before it becomes a problem.
Build automation that survives change
The same principle should also be applied to business rules (SLAs, priority definitions, etc.), which change even more frequently in ITSM. If these rules live inside workflow code, every change requires someone to modify incident workflows, test them against various scenarios, and deploy them during a maintenance window. Store the rules in reference tables, such as:
- An assignment matrix that shows which incident categories route to which groups
- A priority matrix defining impact and urgency combinations
- An SLA table mapping service tiers to response targets
When support teams reorganize, managers should update the assignment matrix through the service portal. Once complete, incident workflows read the new configuration and route tickets differently without requiring any workflow changes. The payoff of this approach is considerable. Your automation practice now adapts instead of breaking, which means you avoid the technical debt trap most organizations fall into.
Value-based automation prioritization
An automation candidate can be a specific process, workflow, task, or business outcome that you're considering for automation. Very commonly, Process Architects identify automation candidates by finding the highest-volume request types and automating those.
Because business outcomes rarely map to a single ITIL practice, the recommended approach instead is to consider cross-practice orchestration to achieve more business value than single-practice automation. ITIL 4's "Think and work holistically" principle champions a cross-functional orchestration by stating that no service, or element used to provide a service, stands alone. Launched in February 2026, ITIL 5's Digital Product Management lens asks how automation contributes to the business product outcomes and customer experience.
If you follow either of the ITIL version principles, you cannot rely solely on ticket volume to identify automation candidates.
When you automate only high-volume requests like password resets and access provisioning, you're optimizing only the Service Request practice, which is just one practice out of 34 in ITIL 4's Service Value System. In the real world, practices such as Incident Management, Problem Management, Change Enablement, and Service Level Management generate fewer tickets but deliver higher business impact per transaction.
To assess the right automation candidates, consider leveraging a comprehensive identification framework or follow an approach listed below.
Volume-based (Foundational tier: Service Request Management)
Can be used to identify opportunities for advancing Service Request Management (and in some cases basic Incident Management) from ad-hoc or defined levels to managed maturity. Here, you're standardizing and systematizing existing processes.
But don't stop at raw volume. Look at volume in context:
- Which high-volume tasks consume your most expensive resources? Automating something that currently requires a senior engineer is more valuable than automating something that can be handled by Level 1.
- Which high-volume tasks have the most variance in quality? If password resets are handled inconsistently, automation brings both efficiency and standardization.
- Which high-volume tasks create bottlenecks for other work? Automating access provisioning might unblock application deployments.
Pain-based (Intelligent tier: Incident, Problem & Service Level Management)
Pain-based automation identification requires actually talking to people, not just analyzing ticket data. Talk to your technical support groups about what frustrates them most. The opportunities they describe often involve coordination overhead, information gathering, and decision-making under uncertainty. These would likely be the activities that consume expertise without adding value and are precisely where intelligent automation creates higher impact per instance.
Risk-based (All tiers: Change Enablement, Security & Availability Management)
Identify processes where human error creates significant risk or cost. Risk-based candidates justify automation even at lower volumes because the cost of failure is high. The ROI is more than just time saved; it's measured in incidents prevented, security exposures avoided, or resources optimized.
The calculation is:
(Probability of failure) × (Cost of failure) × (Reduction in failure rate through automation)
Compare that against automation investment. When failure costs are high, even moderate-volume processes would justify substantial automation investment.
Strategic-based (Transformational tier: Service Design & Continual Improvement)
Look beyond current ITIL practice execution to capabilities that would fundamentally enhance your service value streams or enable competitive differentiation. These candidates often don't appear in ticket analysis because either the capability doesn't exist yet or it's delivered through informal channels that bypass your ITSM tools entirely. Examples include real-time compliance validation during infrastructure changes and automated environment provisioning that includes security configurations by default.
Where to start
It is common for enterprise leaders to accept that they need better automation but they get stuck on where to begin. The right starting point mostly depends on your current situation rather than simply following a universal best practice. Consider a straightforward 90-day automation roadmap as follows.
- First 30 days: Pick one value stream and map it
Choose a stream that matters to revenue or customer experience. Incident resolution, order fulfillment, and employee onboarding are common starting points. Document every step from initiation to completion. Include the handoffs between teams, the approval gates, and the places where work sits waiting. Measure how long each step takes and where delays consistently happen. These delays are where automation delivers the most value because fixing them compresses the entire timeline.
- Next 30 days: Build an abstraction layer for your most frequent integration
Pick the integration your workflows touch most often, such as HR systems, CMDBs, and monitoring tools. Create a configuration layer between your workflows and that system so field names, endpoints, and business rules live in tables instead of hardcoded into workflows. If something changes in the source system, you can simply update a single configuration table rather than finding issues across dozens of workflows.
- Final 30 days: Launch your first risk-based automated remediation
Take one repetitive fix your team does constantly and automate it with guardrails. Restarting stuck services, clearing disk space, and resetting failed jobs are good candidates because they're high volume and low risk. Build the automation with proper safety checks so it can't make things worse. Monitor it closely for the first two weeks to catch edge cases. Once it runs cleanly, you have a template for automating similar tasks.
After 90 days, you'll have a proven approach that works in your environment. You'll have a mapped value stream showing where automation delivers business impact, a reusable integration pattern that survives system changes, and a live remediation workflow saving your team time every day. Use these wins to justify expanding automation to the next value stream or the next integration.
Automating ITSM workflows with SolarWinds
Data from more than 2,000 ITSM systems and over 60,000 incident records (anonymized) shows that automation delivers measurable results when implemented correctly. From August 2024 to July 2025, SolarWinds customers with GenAI enabled collectively saved over 323,000 hours. That time recovery translates into capacity for knowledge development, process refinement, and proactive problem solving.
SolarWinds Service Desk provides automation capabilities across incident management, service requests, and change enablement. The platform includes workflow automation, intelligent ticket routing, automated approvals, and integration with monitoring tools for automatic incident creation. These capabilities work together to compress resolution timelines and reduce manual handoffs.
SolarWinds Report: Resolution Time Before and After GenAI Adoption
The gap between where you are and where automation could take you is often invisible until you map it systematically. SolarWinds' ITSM Maturity Model provides a structured assessment to identify exactly which capabilities to build, eliminate, or automate next.
SolarWinds ITSM Maturity Model
Ready to automate smarter, not just faster? Explore our interactive ITSM maturity model here or try the SolarWinds demo to see how you can orchestrate cross-practice workflows quickly.