ServiceNow ITSM Optimisation

What an ITSM Optimisation Engagement Covers

ITSM Optimisation is not implementation or basic support; it is strategic work to improve how your service desk and operations team deliver IT services. An optimisation engagement audits current operations, identifies improvement opportunities, and guides implementation. The focus is on measurable improvement: faster resolution, higher satisfaction, and better SLA compliance.

Current State Operational Audit

We start by understanding your current state: how many incidents per day, what is the resolution time, what is the SLA compliance rate, which categories take longest to resolve, which teams have the highest workload? We interview staff to understand pain points and inefficiencies.

Process Efficiency Analysis

We trace incident flow from creation to resolution, identifying bottlenecks and inefficiencies. Common issues include: unclear categorization causing misrouting, approvals that take too long, escalations that lose context, handoffs between teams that create delay, missing information causing rework.

Staffing and Workload Optimization

We review staffing levels and skill mix. Are you over-staffed in some areas and under-staffed in others? Can you shift resources to reduce bottlenecks? Can you improve training so staff handle more types of issues? Can you automate routine work to free analysts for complex problems?

Knowledge and Reuse

Many ITSM teams solve the same problems repeatedly instead of building and reusing solutions. We review knowledge management: what are the most common issues? Are resolutions documented? Can staff find them? We help you build a knowledge base that actually reduces resolution time.

Automation Opportunities

We identify which work can be automated: incident categorization, routing, status updates, knowledge recommendations, basic troubleshooting for common issues. We prioritize by impact and ease of implementation so you get quick wins early.

SLA and Performance Target Tuning

SLA targets should be ambitious but achievable. Too aggressive and staff stress trying to meet them; too lenient and they become meaningless. We review your SLA targets: are they appropriate? Should you adjust them? Are they being met?

Tools and Technology Optimization

ITSM depends on good tools. We review your tool configuration: are you using all capabilities? Are tools integrated so information flows between them? Are reports providing insight or just data? We help you optimize technology so it supports your team rather than creating friction.

Measurement and Continuous Improvement

We help you establish metrics that show whether optimisation is working: resolution time trending down, SLA compliance trending up, staff satisfaction improving, customer satisfaction improving. We also help you establish a continuous improvement rhythm: review metrics weekly, identify issues, make small improvements.

Change Management and Staff Adoption

Improvements only work if staff adopt them. We help you communicate changes, train staff on new processes, and support them through the transition. We also help you overcome resistance: if staff do not believe an improvement will work, we address their concerns.

Measuring Optimisation Impact

Success metrics for optimisation engagements differ by organisation. Common metrics include resolution time, SLA compliance rate, staff satisfaction, customer satisfaction, and ticket volume by category. Baseline these metrics before optimisation begins and track them during implementation to understand which improvements are working and which need adjustment. Results depend on starting conditions, the extent of improvement opportunities identified, and the team’s adoption of changes.

Oblytech’s Approach to ITSM Optimisation

We approach optimisation systematically: measure current state, identify opportunities, implement changes, measure improvement. We focus on sustainable improvements that your team can maintain. We also prioritize based on impact: fix the biggest bottlenecks first, then address smaller issues.

Root Cause Analysis of Common Issues

Many ITSM optimisations start with understanding why things take long or fail. Why do incident resolution times vary so widely? Usually because high-severity incidents take longer. But sometimes because certain categories (network issues) are complex and take longer than others (access issues). Understanding root causes lets you optimize specifically where it matters.

Building a Culture of Continuous Improvement

Optimisation is not a one-time project; it is an ongoing mindset. We help you establish rituals: weekly performance review, monthly deep dives into problem areas, quarterly process improvements. We train your team to use data to identify opportunities and track impact of improvements.

Process Automation and Workflow Redesign

Optimisation often requires workflow redesign, not just tuning. Can you eliminate approval steps without creating risk? Can you combine redundant handoffs? Can you automate decisions that staff are making manually? Process redesign can be transformational but requires careful planning and change management.

Change Impact Assessment

ITSM optimisations often change how work is done. We help assess impact: which teams are affected? What training do they need? How will you roll out changes gradually versus all at once? We also help you plan how you will measure success: what will be different after optimisation? How will you know the change worked?

Running optimization as a series of single-variable tests

Optimization work often goes wrong when several things change in one release. Routing is rewritten, the SLA targets are tightened, a knowledge push goes out and an automation is switched on, and then the resolution time moves. Nobody can say which change caused it, so the team argues about the metric instead of the process. A better approach treats each lever as a test: one change, one measurement window, one decision at the end. That approach is slower to start and far faster to learn from.

The levers available in an ITSM service desk are fairly few. Routing rules decide who gets the work. Priority rules decide what gets done first. Knowledge decides whether the first responder can close the ticket. Approvals decide how long a change waits. SLA definitions decide what the report calls late. Automation decides which steps a person no longer touches. Each one moves a different number, and each one can break something else if pushed too far. The automation side of this is covered in the incident management automation guide.

Lever	What it changes	What it can break	Signal to watch
Routing rule	Which group receives a ticket	Tickets bounce between groups and the first responder goes unassigned	Reassignment count per ticket
Priority matrix	Which tickets get attention first	Everything becomes high priority and the queue stops meaning anything	Share of tickets raised to the top priority
Knowledge fix	Whether the first responder can close without escalating	Stale steps are followed and cause repeat failures	Escalations on the topic before and after
Approval path	How long a change waits before work starts	Risk goes unassessed when approval is removed	Lead time and change failure rate together
SLA definition	What the report counts as late	The team games the clock instead of solving the problem	Tickets closed inside the clock but reopened within a short period

Running one change through a controlled test

A single test needs a baseline, a defined window and a rule for stopping. The steps below keep the test honest and make the result usable in the next review. Choosing the metrics for each test is covered in the continual improvement KPI guide.

1. Choose one topic with enough volume to show a change, and write down the metric and the direction you expect.
2. Take a baseline across a full cycle that includes a typical peak, such as month end, so that the comparison is not made against a quiet week.
3. Make one change and record its exact configuration and the date it went live, in the change record, not in a slide.
4. Hold the window long enough for the change to show a pattern, and check the adjacent queues for displacement, because a fix in one group sometimes moves work into another.
5. Decide before looking at the result whether the change stays, is reverted, or is refined. A refinement is a new test.

Why SLA target changes should come last

Adjusting an SLA target is the quickest way to make a dashboard look better and the slowest way to improve service. When a target is loosened, the number improves without any change in how quickly people fix problems. When it is tightened before the process is stable, staff spend their time protecting the clock rather than resolving the issue. Change the targets only after routing, knowledge and approvals have been tested, and only when the existing target no longer matches what the business needs. Record the reason in the change history so that a later reviewer can tell an honest adjustment from a convenient one. How targets are set in the first place is covered in the service level management guide.

Should we change SLA targets before or after fixing routing?

After. Routing errors inflate the time a ticket spends in the wrong queue, so a target set before routing is fixed will be measured against that inflation and will mislead anyone reading the report.

How do we avoid double counting when two fixes ship together?

You usually cannot separate them retrospectively, so avoid shipping them together. If the release calendar forces it, stagger the activation of one fix by a cycle and treat the first cycle as the measure for the first fix.

What should we do if the metric improves but users complain?

Treat the complaint as evidence. A common cause is that the metric measures closure, while users care about whether the problem stayed fixed. Look at reopen rates and repeat contacts from the same requester before trusting the improvement.

Is it worth automating before the process is stable?

Rarely. Automation copies the process it is given. If categorization is inconsistent, an automated routing rule will route the inconsistency faster. Stabilize the steps by hand first, then automate the ones that stayed the same across several cycles. Stabilizing the first steps of incident handling is covered in a practical guide to triage in the first five minutes.

When optimization should stop and a different step should start

If the baseline shows that the largest share of delay sits outside the service desk, such as in suppliers, procurement or the business approval that feeds the ticket, then no ITSM lever will move the headline number much. In that case the useful next step is a process definition across the boundary. If the team keeps running tests without any of them holding, the underlying problem is often capacity or skills, and an ITSM health check is a better use of time than another change.

Choosing the first test is often the hardest step.