ITSM Problem

Management

Process Guide
Rome Release

Ref: 0001029

© 2021 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......................................................................................................................
Problem Coordinator............................................................................................................
Problem Manager.................................................................................................................
Technical Support.................................................................................................................
Specialist Roles....................................................................................................................
How problems are initiated................................................................................................ 6
Problem Management Lifecycle......................................................................................... 7
Process Overview.................................................................................................................
State: New............................................................................................................................
State: Assess........................................................................................................................
State: Root Cause Analysis.................................................................................................
State: Fix in Progress..........................................................................................................
State: Resolved..................................................................................................................
State: Closed......................................................................................................................
Other Processes............................................................................................................... 15
Incident Management.........................................................................................................
Change Management.........................................................................................................
Configuration Management................................................................................................
Knowledge Management....................................................................................................
User Experience.................................................................................................................
Process Governance......................................................................................................... 16
Measurement.....................................................................................................................
Metrics...............................................................................................................................

© 2021 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

Process Scope

© 2021 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 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.

© 2021 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
 Publishing known error articles
 Identifying technical solutions to eliminate faults

© 2021 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.
 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.

Problem Management Lifecycle

© 2021 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.
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

© 2021 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.

© 2021 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.

© 2021 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 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.

State: Root Cause Analysis

© 2021 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 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 Root Cause Analysis problem task to the relevant team who will

© 2021 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.
 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.

State: Fix in Progress

© 2021 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.
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 Management. Incident Management is concerned with the restoration of
© 2021 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.
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.

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.

© 2021 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.
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."

© 2021 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 in

identified for the failure defining root cause

% of problem with workaround Measure the effectiveness of problem management in

defined defining and communicating workarounds

Percentage of incidents resolved Measures the effectiveness of problem management in

by fixing known errors supporting the timely resolution of incidents

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

© 2021 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.
 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 Provides visibility to unassigned work

problems

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

© 2021 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.