ITSM Problem Management

Process Guide
San Diego Release

Ref: 0001029

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Table of Contents
Introduction........................................................................................................................................... 3
Principles and Basic Concepts ........................................................................................................... 3
Process Scope ...................................................................................................................................... 4
Process Objectives ............................................................................................................................... 4
Roles and Responsibilities .................................................................................................................... 4
Process Owner ................................................................................................................................... 4
Problem Coordinator ........................................................................................................................ 5
Problem Manager ............................................................................................................................. 5
Technical Support ............................................................................................................................. 5
Specialist Roles .................................................................................................................................. 6
How problems are initiated ................................................................................................................. 6
Problem Management Lifecycle ....................................................................................................... 7
Process Overview .............................................................................................................................. 7
State: New ......................................................................................................................................... 8
State: Assess ....................................................................................................................................... 9
State: Root Cause Analysis ............................................................................................................ 11
State: Fix in Progress ........................................................................................................................ 13
State: Resolved ................................................................................................................................ 14
State: Closed ................................................................................................................................... 14
Other Processes .................................................................................................................................. 15
Incident Management ................................................................................................................... 15
Change Management................................................................................................................... 15
Configuration Management ......................................................................................................... 15
Knowledge Management ............................................................................................................. 15
User Experience ............................................................................................................................... 15
Process Governance ......................................................................................................................... 16
Measurement .................................................................................................................................. 16
Metrics .............................................................................................................................................. 16

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Introduction
This process guide will provide a detailed explanation on how the problem management
process is enabled within the ServiceNow platform. It is intended that this process be
followed as closely as possible. ServiceNow encourages simple, lean ITSM processes and
that is reflected in the out-of-the-box design. Additional functionality can be incorporated
into what is offered; however, this should only be in scenarios where there is a required
business outcome gained that could not be achieved using an out-of-the-box method.
Following this approach should also ease upgrade paths and the ability to expand the use of
the platform.

Principles and Basic Concepts

A Problem is defined as the underlying cause of one or more incidents. The root cause is not
known at the time a problem record is created, and the problem management process is
responsible for further investigation. A problem can be:
• The occurrence of the same or similar incidents multiple times
• An incident that impacts a service(s) with many users
• The result of diagnostics revealing systems not operating in the expected way that will
lead to an incident. A service impact has not yet occurred

There are three primary goals of the problem management process. The first goal is to
provide a mechanism to understand the cause and permanently solve incidents that have
occurred. These are cases where the incident process may have only identified a temporary
solution purely to restore service. The second goal of the problem management process is to
prevent incidents and service impacts from occurring. Finally, problem management
attempts to minimize the impact of incidents that cannot be prevented.
A Known Error Article is a type of knowledge article the problem management team can
create to help with incident deflection. A workaround or root cause may not be known.
A Root Cause is defined as the underlying or original cause of an Incident or Problem.
A Workaround is defined as a temporary way to restore service failures to a usable level
ServiceNow focuses on the use of automation and information to speed the path to root
cause identification and permanent resolution.
Problem Management relies heavily on:
• The CMDB for problem assignment and impact analysis
• The Incident Management process for providing details of individual related incidents
• The Change Management process for controlling changes needed to solve problems
• The Knowledge Management process for sharing information about known errors

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Process Scope
The scope of Problem Management includes:
• The identification and diagnosis of problems through Event Management, technical
identification, and proactive Problem Management.
• The diagnosis of all problems as quickly as possible using:
o Problem and error control
o Event and incident trends
o Identifying workarounds to reduce incident duration
o Identifying and implementing permanent solutions to eliminate incidents
reoccurring

Process Objectives
The objectives of Problem management are to:
• Determine the root cause of incidents, identify viable workarounds, and drive to
permanent solutions that prevent recurrence
• Maintain information about problems, associated workarounds, and permanent solutions
• Communicate information appropriately to reduce and eliminate the number and
impact of incidents over time
• Identify and solve problems proactively to improve IT services and prevent potential
incidents from occurring

Roles and Responsibilities

Process Owner
The Problem Management Process Owner’s primary objective is to own and maintain the
Problem Management process. The role of the Process Owner is usually a senior manager
with the ability and authority to ensure the process is rolled out and used by all stakeholders.
Responsible for:
• Defining the overall mission of the process
• Establishing and communicating the process mission, goals, and objectives to all
stakeholders
• Documenting and maintaining the process and procedures
• Resolving any cross-functional (departmental) issues
• Ensuring proper staffing and training for execution
• Ensuring consistent execution of the process across the organization
• Monitoring, measuring, and reporting on the effectiveness of the process to senior
management
• Continually improving the process
ServiceNow Role: There is no role in ServiceNow it is a functional role to support the process.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Problem Coordinator
The Problem Coordinator is the responsible owner for getting a problem permanently
resolved or prevented as soon as possible. They must also manage and co-ordinate all
problems through the process.
Responsible for:
• Assessing problems to ensure they are genuine
• Monitoring and controlling the detection, recording, assignment, escalation, and
resolution of problems
• Coordinating technical and service Subject Matter Experts (SMEs)
• Documenting problem information
• Publishing workarounds
• Publishing known error articles
• Coordinating decisions on whether to apply a fix
• Deciding whether to accept the risk of not applying a fix
• Reviewing problems to check for quality and completeness
• Driving the efficiency and effectiveness of the problem management process
ServiceNow Role: The problem_coordinator role is required in ServiceNow.

Problem Manager
The Problem Manager is responsible for the overall Problem Management process and can
configure Problem Management settings as well as act as a Problem Coordinator
Responsible for:
• Can configure whether a problem or problem task can be re-opened and if so by which
roles.
• Can configure whether accepting risk of not fixing this problem moves the problem to
resolved (still active) or closed.
ServiceNow Role: The problem_manager role is required in ServiceNow.

Technical Support
Technical Support teams assist the Problem Coordinator to investigate problems, identify and
implement solutions.
Responsible for:
• Providing subject matter expertise
• Conducting investigation into problems
• Identifying the root cause of problems
• Identifying workarounds, and notifying Service Desk and Technical Support of
workaround availability

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
• Publishing known error articles
• Identifying technical solutions to eliminate faults
• Providing stakeholder communication on active problems
• Resolving problems, through Change Management where applicable
ServiceNow Role: The problem_task_analyst role is required in ServiceNow.

Specialist Roles
Request Read and Write roles
Roles to assign access permissions at a granular level when the ITSM Roles — Problem
Management plugin ([Link].problem_management) is activated.
• sn_problem_read
• sn_problem_write

These roles are added when the ITSM Roles — Problem Management plugin is installed. The
new roles added are:
• sn_problem_read: The user with this role has read access to the Problem
Management application and related records.
• sn_problem_write: The user with this role has write access to the Problem
Management application and related records.

Business Stakeholder Role

The business_stakeholder role to approve, view, or read records across the organization and
view reports.
This role is an extended form of an approver role and contains the sn_incident_read,
sn_problem_read, sn_change_read, sn_request_read, and approver_user roles.
You can assign this role to any user who is a business stakeholder to review and approve
requests only if you have the appropriate entitlement from your organization. This role is
added when the Business Stakeholder plugin ([Link].business_stakeholder) is installed.

How problems are initiated

Directly in ServiceNow - A Service Desk Agent, Incident Manager, Problem Coordinator, or
other IT user can create a problem directly when they believe they see an underlying issue
that is worth investigating.
Directly from an Incident – Incident Managers, Service Desk Analysts, Problem Managers, or
other IT Support staff can raise a problem from an incident where they are seeing evidence
of a problem based on the incident record/s.
Automatically via Integrations - Problems can be automatically generated via external
systems such as a vendor system integration.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Problem Management Lifecycle
States in any ServiceNow application serve a specific purpose. They are designed to make it
clear where in a process a record currently resides and to display progress. States should
represent a unique phase in a process where a specific set of related activities are grouped
together designed to achieve a particular outcome to move to the next phase of the
process. Our recommended Problem Management process has the following state model:
• New
• Assess
• Root Cause Analysis
• Fix in Progress
• Resolved
• Closed

Process Overview

Mark Duplicate / Cancel

Re Analyize

Root Cause
New Access Fix in Progress Resolved Closed
Analysis

Access Confirm Fix Resolved Complete

Mark Duplicate / Cancel / Accept Risk

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
State: New

When a problem is first created, it is in a state of New. This is where very basic information is
added that may suggest a problem exists. All known information about the symptoms
experienced is captured, with enough information to warrant an investigation.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
The mandatory fields are:
• Problem statement
If other fields such as CIs are known at this point, they can still be added and will be
automatically if they are coming from an existing incident record; however, they do not
need to be mandatory to progress. In addition, if the fields in the Assess Dialog Form View
dialog are filled, the problem is automatically moved to the Assess state without having to
manually change the state

Problem Assignment

At the New state, it is necessary to identify the appropriate assignment group to assess the
problem in the next phase of the lifecycle. This will need to be a Problem Management
group or if a dedicated function does not exist in the organization then the group that will
perform that function such as the Service Owner or Incident Management team, these users
will require the problem_coordinator role. This assignment is best achieved by automatically
updating the Assignment group field rather than letting the user try to pick the correct group
manually since this approach is prone to error.
At this point, if the assignment group is automatically updated, a member of the group will
need to choose an individual Problem Coordinator to take responsibility for the problem on
behalf of the group. This is done by populating the Assigned to field.
Once the fields are populated, the problem coordinator is expected to click the Assess
button. If the “Assigned To” field has not been populated, it will need to be populated in the
Assess state. This will move the problem into the lifecycle where it is considered ‘live’ and
something that requires attention.

State: Assess
At the Assess state, the Problem Coordinator is primarily assessing the problem to determine
whether it is genuine or not.
The new Assigned to individual (the Problem Coordinator) will now conduct an initial review
of the problem primarily to check that it is indeed a real problem.
• If the Problem Coordinator determines that this is a duplicate problem, he or she will
click Mark Duplicate and select the problem this is a duplicate of.
• If the Problem Coordinator recognizes it is not a genuine problem, he or she will click
Cancel and populate a Work Note to explain why the problem is not considered to
be genuine and explain why no further investigation is required.
• If the Problem Coordinator is comfortable to proceed with the investigation, he or she
should update the Priority, Service, and CI before clicking Confirm.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Establishing Priority

Problem prioritization typically drives the criticality associated with the handling of the
problem and the order in which problems will be focused on. Priority is calculated through a
combination of Impact and Urgency.
Impact is the affect that a problem has on business.
Urgency is the extent to which the problem’s resolution can bear delay.
Priority is generated from urgency and impact according to the following table.

Urgency

1 - High 2 – Medium 3 - Low

Priority Priority Priority

1 - High
1 - Critical 2 - High 3 - Medium

Priority Priority Priority

Impact 2 - Medium
2 - High 3 - Medium 4 - Low

Priority Priority Priority

3 - Low
3 - Medium 4 - Low 4 - Low

It is possible to automatically establish the priority of the problem based on the CI that is
identified in the problem record. With this technique, the business criticality value of the CI is
used to determine the priority of the problem. For example, an online banking service would
be considered critical to a financial organization. If this CI is related to the problem the
priority can be automatically set to Critical as a result. This ensures a more accurate and
consistent prioritization of problem, as the determination of impact and urgency can be a
subjective call. If this automated method is being used this can occur at the New state
when the problem is first raised as it will be helpful to the Problem Coordinator to see this
immediately.

Services and CIs

The Service and CI fields are used to identify what is being impacted by the problem. These
fields use CMDB data which is also used across other ITSM processes therefore creating a
valuable link and traceability particularly for services. This also offers the use of the
Dependency Views feature that displays the relationship map from the service/CI in question
to other related CMDB components and will display any ongoing incidents or changes that
may exist to aid with root cause analysis.
If the Agile Development application is in use, existing defects should be searched to look for
possible causes or relationships to the problem.
Once this data has been entered the Problem Coordinator will click Confirm to move to the
Root Cause Analysis state.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
State: Root Cause Analysis

The Problem Coordinator may now need to engage one or more technical support teams to
investigate and potentially help fix the problem. This is achieved using Problem Tasks.

Problem Tasks
The parent problem record remains assigned to the Problem Coordinator throughout the
entire process. The Coordinator creates and assigns individual tasks out to the various
technical support teams to aid in the investigation and diagnosis. Each team will capture
their own investigation and discoveries in their individual tasks and the Problem Coordinator
will review and coordinate them all. There are two types of problem tasks. Root Cause
Analysis and General. The RCA type should be selected for specific tasks required to
investigate the root cause and should be created by the Problem Coordinator at this point.
During the Root Cause Analysis state four main activities are intended to occur:
1. Discover a workaround (if possible), the Problem Coordinator should enter it into the
Workaround field and communicate it to all open related incidents using the
Communicate Workaround related link. This populates the text from the Workaround
field into the Activity Log of all related open incidents explaining that it is a
workaround from the problem record.
2. Discover the root cause and document if using the Cause notes field on the problem.
If the Problem Coordinator needs help to discover the root cause, they can assign a

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
 Root Cause Analysis problem task to the relevant team who will attempt to
document the cause code, cause notes, proposed fix and provide a workaround on
the problem task.
3. Discover a permanent fix for the problem to prevent it from happening in the future,
enter it into the Fix notes field and communicate it to all open incidents using the
Communicate Fix related link. As with the root cause, if the Problem Coordinator
needs help to discover a permanent fix, they can use a problem task to gather that
information.
4. As it could take time to implement a permanent fix it may be helpful to communicate
that this problem is known about and currently being worked on which can help to
deflect incidents. The Problem Coordinator should create and publish a Known Error
knowledge article. Known Error articles show up when an end user goes to create an
Incident via the Portal. Click the Create Known Error article related link to create a
Known Error article from a problem which creates a link between the two records
displayed in the Primary Known Error article. On the problem record. The Problem
statement, Description, Workaround and Cause notes are copied over when creating
a Known Error article. The Known Error article will be in the draft state and can then be
published. If it is not deemed necessary to publish the known error in the Knowledge
Base, Service Desk Analysts and other Technical Support users can simply search for
all problems to find these and use the information as they require it. Most commonly
this will be used by the Service Desk if they are trying to resolve an incident, find a
workaround or if they recognize a pattern of similar incidents.
These activities can all happen in parallel and may be discovered at different times through
Root Cause Analysis. It is possible that none of these are discovered, some or all four.
If the root cause and a permanent fix are discovered, then the problem can be moved to
the Fix in Progress state using the Fix button. If a fix cannot be discovered or the fix cannot be
implemented, the Problem Coordinator can use the Accept Risk button and provide reason
why they are accepting the risk of not fixing this problem for now.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
State: Fix in Progress

Fix in Progress state represents a problem that has been investigated and is now needing a
fix. At this state it becomes mandatory to enter Cause notes and Fix notes.
The Problem Coordinator can create or relate to one or more Change Requests to show the
clear path to resolution.
Once the change(s) are implemented and the problem considered to be resolved the State
field is now updated to Resolved using the Resolve button.

Risk Accepted

From the Root Cause Analysis or Fix in Progress states, the Problem Coordinator can accept
the risk of not fixing the problem for now:
• Due to cost implications the business may determine it is not worth the cost of fixing
• A fix cannot be determined
The resolution code is set to Risk Accepted.
Risk Accepted problems in these situations can be reviewed by the Problem Coordinator at
appropriate intervals. The coordinator establishes whether the impact has increased, or the
situation has changed to the point where either the problem will be fixed or is no longer
required due to some other change that has occurred and resolved it. The Problem
Coordinator can then choose to re-analyze the problem, so the problem process can then
be worked through to find the solution.
The out-of-the-box default is that Risk Accepted problems are set to Closed because there is
currently no work to do on the problem at that time. You can easily see the list of Risk
Accepted problems whether they are active or closed. The overall concept is that a
problem is only active if there is work that needs to be done on it right now.
Risk Accepted problems should be set to Resolved and can remain in Resolved indefinitely.
It is important to remember that this is a key difference between Incident and Problem

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Management. Incident Management is concerned with the restoration of service as quickly
as possible using whatever means possible. Problem Management is concerned with
permanently resolving the issue and ensuring it will not reoccur - therefore it is acceptable for
this to take as much time as is required. There should be no driver to close out unresolved
problems purely because they are not going to be fixed at that time and are sitting in a list of
active problems.

State: Resolved
Once the problem has been moved to Resolved state the Assigned to individual will need to
populate the Mandatory Fix notes field with text to describe exactly what has been done to
solve the issue.
At the Resolved state it is also possible for an organization to conduct a review of the
problem if their process requires it. Additional fields can be added here to capture that
information. Alternatively, problem tasks can be assigned out by the Problem Coordinator as
required.
A set period can also be observed before setting the problem to Closed state to confirm that
the known error has been solved. If evidence suggests that the issue persists, the state can
be set back to Root Cause Analysis using the Re-analyze button. The process can then be
worked through again to continue to find the solution.
If the problem is confidently considered solved, then the Assigned to individual will close the
problem using the Complete button.
State: Closed
At Closed state, several Resolution codes are displayed. These are automatically
determined by certain actions that occurred during the process:
• Duplicate
The problem was marked as a duplicate of another problem. Any related incidents
and tasks will be moved over to the problem that this one is a duplicate of. This is
configurable in the problem properties.
• Canceled
The problem was canceled. There are very few scenarios where a problem is
genuinely canceled. This will only occur when a problem was raised in error usually
prematurely before realizing there is no real problem.
• Fix Applied
A permanent fix was applied, and the problem was resolved.
• Risk Accepted
The problem has not been resolved but it has been accepted that the solution is not
to be applied at this time. If that decision changes the problem can revert
The problem management properties determine whether a closed problem can be re-
analyzed. For example, additional incidents were added to this problem after the fix was
applied. Set the role to Nobody if you do not want to be able to re-analyze the problem.
Then if the problem reoccurs, create a new problem ticket, and set the “First reported by”
field to refer back to this problem so you can trace it.

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Other Processes
Incident Management
Most problem records are triggered in reaction to one or more incidents. Incident history
helps identify trends or potential weaknesses as part of proactive problem management.
Incident records that are related to problem records which are pending resolution, are
automatically updated when a problem is resolved.

Change Management
For problems, implementing the workaround or the permanent solution will require work on a
service, hardware, or software. Conducting this work will require a change record to be
raised. This is done by selecting the Create Normal Change or Create Emergency Change
option in the context menu.
Emergency changes typically require an incident record to be related to prove that they are
urgent enough to bypass the full process and lead times.

Configuration Management
The configuration management system underpins all records and activities related to any CI.
It contains details of the infrastructure vital to services, CIs, and their relationships.
The CMDB is used within the problem management process by relating Configuration Items
including Services to the problem. This allows Dependency Views to be used which display
the relationship between the selected CI and other CIs related up and downstream.

Knowledge Management
Knowledge is a vital part of the problem process. Known errors are documented and
published in the knowledge base including workaround information to allow end users to see
knowledge articles and, if appropriate, make use of workaround information to help
themselves while the known error is being fixed.

User Experience
Mobile platforms and Virtual technology can have a positive impact on how end users interact with the
end-to-end process and ultimately how the entire user experience is perceived. Consider which touch
point in the process can leverage the mobile platform to minimize delays in the process. Tasks such as
chat can all be performed on mobile devices. Consider also how Virtual agent can be deployed to
assist users in common actions and tracking progress."

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Process Governance
Measurement
Key Performance Indicators (KPIs) evaluate the success of a particular activity toward
meeting the critical success factors. Successfully managing KPIs can be either through
repeatedly meeting an objective (maintain) or by making progress toward an objective
(increase/decrease). The Benchmarks feature gives you instant visibility into your key
performance indicators (KPIs) and trends, as well as comparative insight relative to industry
averages of your peers. You can contrast the performance of your organization with
recognized industry standards and view a side-by-side comparison of performance with
global benchmarks.
The main point of note when creating any KPIs or metrics for problem management is not to
be driven by the same measurements used for incident management. With incidents the
purpose of the process is to restore service as quickly as possible using whatever means
available. Therefore, speed of resolution is a key measurement for this process. With
problem management the purpose is to understand the underlying cause of issues and
permanently fix them no matter how long that takes or if it is even possible. Therefore, in
problem management speed of resolution is not something that should be measured. This
would drive the wrong behavior for the process and focus on closing records rather than
finding the permanent fix. Process Owners need to feel comfortable with problem records
potentially remaining open for months or even years.

Metrics
Process KPIs
• Provide information on the effectiveness of the process and the impact of continuous
improvement efforts
• Are best represented as trend lines and tracked over time
• Monitored by the Process Owner

Item Purpose

Mean time to first respond to Measure of how well response SLAs are achieved
problems, by priority

% of problems with a root cause Measure the effectiveness of problem management

identified for the failure in defining root cause

% of problem with workaround Measure the effectiveness of problem management

defined in defining and communicating workarounds

Percentage of incidents resolved by Measures the effectiveness of problem management

fixing known errors in supporting the timely resolution of incidents

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.
Operational Data
Active catalog items/requests that require visibility, oversight, and possible management
intervention are best tracked on a dashboard or homepage that is monitored by the Service
Desk and request fulfilment team.

Item Purpose

Problems ready to be assessed Shows all problems that require a Problem Coordinator
to assess them

List of active problems that have Highlights where there may be a process issue in
missed target response times assessing new problems

Aged list of backlogged problems Provides visibility to unassigned work

Risk Accepted problems with new Highlights where a risk accepted problem may need to
incidents be reviewed for further work

© 2022 ServiceNow, Inc. All rights reserved.

ServiceNow, the ServiceNow logo, Now, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow, Inc., in the United States
and/or other countries. Other company names, product names, and logos may be trademarks of the respective companies with which they are
associated.