ServiceNow ITSM Health Check

An ITSM health check is a structured review of incident, change and problem management, service level measures, knowledge use, staffing and configuration. It shows whether the platform supports the processes a team actually runs, and it turns the findings into a prioritised set of decisions the team can own.

An ITSM health check only holds up if the review question is settled before anyone pulls a report. This page covers the incident, change and problem management evaluations, service level and metric validity, knowledge effectiveness, staffing and process capability, configuration and automation use, recommendations and prioritisation, the evidence pack to assemble before the assessors arrive, where reviews go wrong, turning findings into decisions the team can own, and when a health check is the wrong next step.

Incident Management Workflow Evaluation

We evaluate incident management: how incidents flow from creation through resolution. We assess: are incidents being created consistently (or are issues resolved verbally and never logged), are severity and priority assessed accurately, are incidents routed to correct resolution groups, are resolution SLAs being met. We interview incident owners: do they understand SLA definitions, do they know how to escalate, do they take ownership of resolution. We measure: incident volume trends, MTTR (mean time to resolution), first-contact resolution rate, repeat incident rate (are same issues recurring). Common findings: incident creation is inconsistent (some tickets bypass ITSM), SLAs are defined but not monitored, routing rules are outdated and send incidents to wrong groups, escalation procedures are unclear. We assess overall process health: is incident management preventing issues from becoming crises, or just tracking failures after they happen.

Change Management Implementation and Risk Control

We evaluate change management: how changes are requested, approved, implemented, and validated. We assess: are all changes going through change management or are some bypassed, are changes categorized appropriately (standard versus complex versus emergency), is impact assessment being done, are changes properly tested before production. We review change approval workflow: who is approving changes, do approvers have authority, are approvals timely or do changes get stuck waiting. We measure change success: what percentage of changes succeed versus fail, what causes failures (insufficient testing, inadequate communication, wrong dependencies), how long is rollback required after failed changes. Common findings: change process is viewed as bureaucracy and bypassed, testing is insufficient, approvals are slow, communication before changes is poor. We assess: is change management protecting infrastructure or just creating delays.

Problem Management Maturity Assessment

We evaluate problem management: does your organization identify and resolve root causes of recurring issues, or does it just treat symptoms. We assess: do problems get recorded, are RCA (root cause analysis) investigations conducted, are problems investigated systematically or ad-hoc, are permanent solutions implemented or is it just quick fixes. We interview technical staff: do they understand problem management process, do they participate in RCA, are they implementing recommendations from problem investigations. We measure: problem volume, incident recurrence rate (if problems are solved, recurrence should be decreasing), MTRS (mean time to resolution) for problems. Common findings: problem management isn’t used at all (incidents get resolved without investigating root cause), RCA is performed superficially (identify one cause without investigating fully), RCA recommendations aren’t implemented (problem solves incident but doesn’t prevent recurrence). We assess: is organization learning from failures and becoming more stable, or just firefighting repeatedly.

Service Level Agreements and Metrics Validity

We evaluate SLA definitions: are SLAs realistic (achievable with current resources), meaningful (measure what matters to business), and monitored (tracked and acted upon). We assess: SLA response times, resolution times, business hours versus 24/7, prioritization scheme (how is urgent versus low-priority determined). We measure SLA compliance: what percentage of incidents meet SLA target, which services consistently miss SLA, which services exceed SLA (might be overly conservative). Common findings: SLAs are defined but nobody knows them, SLAs don’t account for severity or priority, SLA targets are unrealistic, SLA metrics are tracked but not used to drive improvements. We assess: do SLAs motivate right behaviors, or create perverse incentives (closing tickets without resolution to meet SLA).

Knowledge Management and Documentation Effectiveness

We evaluate knowledge base: does it support incident resolution, how often is it used. We assess: knowledge article quality (are articles accurate and current), coverage (what percentage of common problems have documentation), accessibility (can support teams find answers easily), usage (is Virtual Agent or support staff using knowledge). We measure: knowledge base size, article update frequency (old articles indicate knowledge isn’t maintained), article usage rate (do support staff reference knowledge when resolving issues), knowledge base contribution rate (are engineers creating documentation). Common findings: knowledge base is built but not maintained (articles become obsolete), knowledge base isn’t used (staff prefer calling experts than searching articles), knowledge articles are hard to find (poor categorization). We assess: is organization capturing and sharing knowledge, or does every problem require expert intervention.

Staffing and Process Capability Assessment

We evaluate operational capability: does your team have skills and resources needed to run ITSM effectively. We assess: team size, skill distribution (are specialists available when needed), training levels (how many staff are trained in ITSM), turnover (is knowledge leaving organization). We interview managers: do they have adequate headcount to handle ticket volume, do they have time for improvement work beyond daily tickets, what are biggest operational challenges. Common findings: team is understaffed relative to ticket volume, team lacks ITSM process training, staffing is uneven (some specialties are over-invested while others lack resources). We assess: is team capability aligned to operational needs, or are people constantly overwhelmed.

Technology Configuration and Automation Utilization

We evaluate ServiceNow configuration: is ITSM configured to support processes or is configuration outdated. We assess: workflow automation (are repetitive tasks automated or done manually), integration (does ITSM integrate with other systems or are manual handoffs), reporting (are metrics being tracked and reported), governance (are configuration changes controlled). Common findings: configuration was done during implementation but rarely updated, automation opportunities are missed, integrations are manual and error-prone, reporting is basic. We assess: is ITSM technology being fully utilized, or is configuration limiting effectiveness.

Recommendations and Prioritization

Health check concludes with prioritized recommendations: quick wins (easy improvements with high impact), critical improvements (addressing major process gaps), strategic improvements (aligning ITSM to business strategy). We prioritize based on: impact (how much will this improve), effort (how much work to implement), risk (could implementation cause problems). We also provide roadmap: if you have limited capacity, which improvements should you do first, what is realistic timeframe for implementation. Final report includes: assessment findings, metrics analysis, benchmarking against industry, recommendations with business case, implementation roadmap. Health check results help leadership decide whether to invest in ITSM optimization and where to focus improvement efforts.

Settle the review question before anyone pulls a report

A health check on ITSM is only as useful as the question it was commissioned to answer. A common reason a review disappoints is that the sponsor wanted reassurance that the platform was sound, while the assessors went looking for process failures. Those are different jobs. A reassurance review samples the configuration and the best-run queues. A failure hunt pulls every stale task, every reopened record and every change that needed a second attempt. Before the work starts, the sponsor should write down which of four purposes applies, because each one changes the data pulled, the people interviewed and how much weight the report gives to configuration compared with behavior.

The second decision is the boundary. ITSM touches incident, change, problem, request and knowledge work, and a review that covers all of them at equal depth often produces a long report that nobody acts on. Start with the process where the business feels pain, such as major incidents that reopen or changes that cause a second outage, and widen the review only if that first slice shows the cause sits upstream. A practical guide to baselining an ITSM process before any review starts is a useful companion to this section.

Decision to settle first	Choose this when	What the review must produce
Budget justification	Leadership is deciding whether to fund more ITSM work	A costed list of gaps, each with the effort it needs
Stalled metric investigation	A KPI has not moved across several reporting cycles	The process step or data field holding it back, with worked examples
New owner baseline	A new service owner inherits the platform	A current-state map and a short list of risks to watch
Scope reduction	Teams are overloaded by too many parallel fixes	A ranked shortlist that includes what to stop doing

An evidence pack to assemble before the assessors arrive

Reviews are cheap to run when the data is ready and expensive when assessors have to request exports one at a time. The pack below lets interviews start on day one with specific questions instead of general ones.

1. Export task SLA records for incidents and requests across the review window, including the stage at which each clock paused or was cancelled and the reason recorded.
2. Pull change records with type, risk level, approval history, assignment group and close code, so that standard, normal and emergency changes can be read separately.
3. List problem records with their linked incidents and the date a root cause was recorded, to test whether investigation happens at all or only on paper.
4. Count reopened incidents and incidents closed without a resolution note, grouped by assignment group, so the owners of the pattern are visible from the start.
5. Collect the assignment rules and routing conditions with the date each one last changed and the list of users who hold approval roles.
6. Gather knowledge articles that were viewed from an incident but never linked to it. These show where people looked, found nothing usable and went to a colleague instead.

Where reviews go wrong and the signs to watch for

Most weak reviews fail in predictable ways, and the sponsor can check for each one while the work is still running. Keeping review actions on a working cycle is the subject of the continual improvement management guide.

• Interviews are held without the people who touch the records every day, so the findings describe the process as written rather than as practised.
• Paused SLA clocks are read as slow teams when the pauses reflect real waiting on a customer or a third party.
• Approval delay is blamed on the approvers when most of the wait sits in impact assessment that was never assigned to anyone.
• Configuration is judged against an untouched product default that few working organizations keep.
• Every finding is given the same weight, so the three items that matter most are buried among thirty minor ones.

Turning findings into decisions the team can own

Sort each finding into one of three groups: fix now, plan for later, or accept. The accept group is legitimate. A rarely used report that nobody reads may not justify rebuilding, and naming that explicitly prevents it returning in the next review. Every finding that stays in the fix or plan group needs an owner who was not the assessor, because a finding owned by the reviewer tends to be filed rather than acted on. Incident metrics are covered in the incident management metrics guide.

Should we run a self-assessment before commissioning an outside review?

Yes, and it should be short. Ask the service owner and two shift leads to list the five places where ITSM slows them down, then compare that list with the evidence pack. Where the two lists agree, the review can go straight to root causes. Where they disagree, the review should spend its first week finding out why people feel a problem the data does not show, or the reverse.

Who should sit in the interviews?

Include one person who raises incidents, one who approves changes, one who works problems and one who manages SLA reporting. Interview them separately and then together. Separate interviews surface what people will not say in front of a manager, and a joint session tests whether their accounts of the same process match.

What if the platform looks healthy but users say it is not?

Treat that gap as evidence that needs its own explanation. A healthy configuration with unhappy users often means the workflow fits the design document but not the way work arrives. Check whether requests come in through email or chat outside the platform, whether agents re-key information into the form, and whether required fields force guesses. Those are process problems that no configuration report will show.

Can the same review be repeated, and how often is useful?

A calendar-driven repeat tends to re-discover the same findings. A repeat that asks the original questions again shows whether the actions held and where they did not. Where the findings call for a sustained program rather than a one-off review, the ITSM optimization service covers that work.

When a health check is the wrong next step

If the team has no agreed definition of resolved, a review will measure the disagreement rather than the process, so the definition work comes first. If headcount is the real constraint, a review will confirm it at real cost and the outcome will be the same as before. If a major rollout is weeks away, the review competes with the rollout for the same people. In each case the sensible order is a short process definition exercise, then the review. Where the review leads to target changes, the service level management guide covers how service level agreements set response and resolution expectations.