Incident Management - Design

ITSM Incident Management
Design
Document
Table of Contents
Introduction.....................................................................................................................................................................4
Principles and Basic Concepts........................................................................................................................................4
Process Scope..................................................................................................................................................................5
Process Objectives..........................................................................................................................................................5
Roles and Responsibilities..............................................................................................................................................6
Groups.........................................................................................................................................................................9
How incidents are initiated...........................................................................................................................................10
Implementation Insight:............................................................................................................................................10
Incident Management Lifecycle...................................................................................................................................11
Incident State Model.................................................................................................................................................11
Process Overview......................................................................................................................................................12
State: New.................................................................................................................................................................12
State: In Progress.......................................................................................................................................................18
State: On Hold...........................................................................................................................................................19
State: Resolved..........................................................................................................................................................20
State: Closed..............................................................................................................................................................21
State: Canceled..........................................................................................................................................................21
Incident Tasks and Parent / Child incidents..............................................................................................................21
Parent and Child Incidents............................................................................................................................................22
Handling Ad Hoc Questions/Help................................................................................................................................22
Incident Escalations......................................................................................................................................................23
Functional escalation.................................................................................................................................................23
Hierarchical escalation..............................................................................................................................................23
Other Processes.............................................................................................................................................................24
Major Incident Management.....................................................................................................................................24
Change Management.................................................................................................................................................24
Problem Management...............................................................................................................................................24
Configuration Management.......................................................................................................................................25
Knowledge Management...........................................................................................................................................25
Service Level Management.......................................................................................................................................25
User Experience........................................................................................................................................................25
Advanced Work Assignment for Incident.................................................................................................................26
Incident Management and CSDM................................................................................................................................27
Populate Impacted Services based on Affected CIs..................................................................................................28
2
© 2024 ServiceNow, Inc. All rights reserved. ServiceNow, the ServiceNow logo, Now, Now Platform, and other ServiceNow marks are trademarks and/or registered trademarks of ServiceNow,
Inc. in the United States and/or other countries. Other company and product names may be trademarks of the respective companies with which they are associated.
Populate the Business Application related list for Incidents.....................................................................................28
Process Governance......................................................................................................................................................30
Outcome based approach..........................................................................................................................................30
Process and Operational KPI’s..................................................................................................................................33
Benchmarks...............................................................................................................................................................34
Reports and Homepages............................................................................................................................................34
Process Diagrams..........................................................................................................................................................35
Process Scoping Considerations...................................................................................................................................35
3
Introduction
This process guide will provide a detailed explanation of how the incident 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

An Incident is defined as an unplanned interruption to a service or reduction in the quality of a service.
Incidents can include failures or degradation of services reported by users, technical staff, third-party suppliers and
partners, or automatically from monitoring tools.
The purpose of the incident management process is to minimize the negative impact of incidents by restoring normal
service operation as quickly as possible.
Normal service operation is defined as an operational state where services and CIs are performing within agreed
service and operational levels.
Incident management is responsible for managing the lifecycle of all incidents. A temporary workaround to restore
service is all that is required in many cases to complete the process.
ServiceNow focuses on the use of automation and information to speed the path to resolution.
Incident Management relies heavily on:
 The Configuration Management process for incident assignment and impact analysis.
 The Problem Management process for investigating root causes of incidents and providing workarounds and
permanent resolutions.
 The Change Management process for controlling changes needed to resolve incidents and minimize incidents
caused by change.
4
Process Scope
The scope of Incident Management includes:
 The identification and diagnosis of incidents through Event Management, Technical identification, and user-
reported
 The resolution of all incidents as quickly as possible using:
o Defined resolution processes
o Problem Management identified Known Errors (workarounds)
o Identifying new resolution activities through diagnosis.
 Identifying incidents and groups of incidents that require further analysis in the Problem Management process
for elimination or reduction in resolution time.
Process Objectives
The objectives of Incident Management are to:
 Ensure standard methods and procedures are used for efficient and prompt incident response, analysis,
documentation, management, and reporting.
 Increase visibility and communication of incidents to business and support staff.
 Enhance the business perception of IT through the use of a professional approach in quickly resolving and
communicating incidents when they occur.
 Align Incident Management activities and priorities with those of the business.
 Maintain user satisfaction with the quality of IT service.
5
Roles and Responsibilities
Role Name Caller
Description The Caller is the individual who is being impacted by degradation to a service or someone who has
discovered an impact/potential impact to a service. This could be a member of an operational support
team. Alternatively, if the issue has been discovered automatically through an event monitoring system,
then the Caller may be captured against that system.
Responsibility  Bringing incidents to the attention of the Service Desk

 Participating in the implementation of a solution or workaround
 Confirming successful resolution
ServiceNow Role No role is required in ServiceNow for this; however, a login will be needed.
Role Name Service Desk Agent (1st Line)
Description The Service Desk Agent (SDA) is the front line or face of the Technology organization. They will be
the people the rest of the organization interacts with most commonly and this will typically be when
users are experiencing some sort of technology related issue. The goal of the SDA is to deal with as
many incidents as possible themselves at the point of receiving the incident. This is first call or initial
contact resolution. Ideally, they want to solve the Callers issue immediately without having to involve
other support teams and without the Caller having to contact them a second time.
Even if the issue cannot be dealt with by the SDA, many organizations will keep ownership and
communication of the incident with the SDA even though others may be providing the actual
resolution.
Since the SDA is expected to resolve incidents themselves, they need a very broad range of knowledge
across all technical services, they may be considered a ‘jack of all trades, master of none.’ This means
they need access to information to help with their diagnosis, as they are likely to have limited
knowledge on each subject. They must at least try to determine a good line of investigation so that they
can pass the incident to the correct IT Support team for further diagnosis.
Responsibility  Recording, ownership, monitoring, tracking, and communication about incidents

 Investigating and diagnosing incidents
 Providing resolutions and workarounds from standard operating procedures and existing known
errors
 Escalating incidents to IT support
 Communicating with the caller
The Service Desk Agent is engaged in the process by setting the Assignment Group field to the
Service Desk group and the Assigned to field to the individual SDA.
ServiceNow Role Service Desk Agents will require the itil role, or sn_incident_read and sn_incident_write roles.
6
Role Name IT Support Teams (2nd / 3rd Line)
Description If a Service Desk Agent is unable to resolve an incident on their own, they must pass responsibility
to someone else who will have more knowledge and experience. Organizations will differ in how
they structure their support teams however a common approach would be to have 2nd line support
teams within the Service Desk reporting structure who specialize in particular services and would be
considered the Subject Matter Experts (SMEs) for these services. Escalating to 2nd line would still
keep the incident within the Service Desk.
3rd line support is typically the operational team responsible for the service. For example, Database
Support, Network Support, Application Development etc. These are the teams whose main focus is
the delivery and maintenance of that service.
4th line support may not need to exist in many organizations, but this could be where the service is
supplied by an external vendor and all internal support teams have failed to resolve the issue. The
incident now needs to be escalated outside of the organization.
Essentially the higher the line of support the more knowledge and experience they should have on
the specific service in question, the less general knowledge they will have across all services.
Responsibility  Investigating and diagnosing incidents escalated from the Service Desk
 Developing workarounds
 Resolving and recovery of assigned incidents
 Creating incidents after detecting a service failure or quality degradation or a situation that may
result in one
The IT Support Team is engaged in the process by changing the Assignment Group field to the
support group in question and the Assigned to field to the individual support staff.
ServiceNow Role SMEs will require the itil role, or sn_incident_read and sn_incident_write roles.
Role Name Incident Admin
Description The incident management process owner can configure certain elements of the incident process that
do not require the System Admin to do so
Responsibility
 Configuring incident properties
 Configuring major incident trigger rules
ServiceNow Role The incident_manager role is required for incident administration.
7
Role Name Incident Management Process Owner
Description The Incident Management Process Owner’s primary objective is to own and maintain the Incident
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.
Responsibility  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
 Directing the Incident Management roles
 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 The business_stakeholder role can be used for incident process management.
See the ITSM Roles plugin to provide more granular roles across ITSM applications as well as within them. Note:
OOB, the ITIL role allows users to modify the CMDB/CI, which may not be desirable.
8
Groups
The assignment group and the selected assigned have a responsibility to work on the task.
Group Name Service Desk Group(s) (1st line)

Responsibility  Recording, ownership, monitoring, tracking, and communication about incidents
 Investigating and diagnosing incidents
 Providing resolutions and workarounds from standard operating procedures and existing known
errors
 Escalating incidents to incident support
 Closing of incidents
ServiceNow Role ITIL
Group Name IT Support Team (2nd/3rd line)

Responsibility  Investigating and diagnosing incidents escalated from the service desk
 Developing workarounds
 Resolving and recovery of assigned incidents
 Creating incidents after detecting a service failure or quality degradation or a situation that may
result in one
ServiceNow Role ITIL
Some examples of assignment groups are:

 Service Desk
 Network Administrators
 Server Administrators
 Database Administrators
 Application Developers
These groups can also have a hierarchical structure
When defining groups, there are some leading practices to be considered:
1. Define group types
2. Align on group naming conventions
3. Establish group structure and framework
4. Create persona groups
5. Assign roles to groups, add users to groups
6. Streamline group creation and management
7. Create a group management dashboard
See User and Group Management - Leading Practices for further detail
9
How incidents are initiated
Channel Description
Directly in The Service Desk Agent can create the incident directly because of a phone call or email from a user.
ServiceNow A member of IT Support can raise an incident when they discover evidence of one.
Self Service End users can make use of the portal where they can directly create a ticket. This would use a record
producer to generate an incident record rather than exposing the full incident form to users that
would not understand most of it.
Automatically via Incidents can be automatically generated via external systems such as event monitoring.
Integrations
Support Chat A Service Agent can generate incidents using chat conversations with a user. The chat log is
included in the Incident Activity Log and a link to the Incident and the user is set.
Inbound Email Inbound emails can generate incident records. ServiceNow does not recommend this method since it
cannot reliably collect enough information from the email to create an incident that can be worked
on.
Walk Up Experience An incident can be created using the Walk-Up interface when a user visits the onsite IT support
location
Implementation Insight:
Email is sometimes the predominant entry point for incidents, although it is also the most inconvenient from a
functionality point of view. The only attributes you can gather from email are the user (sender), the short description
(subject), and the description (email body). But what about the service, Configuration Item, or urgency? Important
mandatory fields are left out, and often, the agent needs further information, which results in more work for the
agents.
It is recommended to eliminate email as an entry channel and introduce other smart ways to submit incidents. There
may be a short period of resistance, but in the end, the process will become more efficient. You can do this by:
 Facilitate organizational change management to help with the change and bring the stakeholders on board.
 Make the process as efficient as possible (e.g., for a call to the Service Desk, integrate a CTI solution so that the
agent does not need to fill out the caller's information).
 Set up an easy interface in the service portal, asking the user only for information that can be easily provided
and only the most important information.
 Provide a mobile interface to allow users to submit an Incident in a quick and smart manner.
10
Incident Management Lifecycle
States in any ServiceNow application serve a specific purpose. They are designed to make it clear where in a process
a particular 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 and designed to achieve a particular outcome to move
to the next phase of the process. For example, in Incident Management, the Resolved state should contain all
activities required to understand what was done to resolve the incident. It would not be expected that resolution
explanation activities would occur during other states. Out-of-the-box Incident Management has the following state
model:
 New
 In Progress
 On Hold
 Resolved
 Closed
 Canceled
Incident State Model
Cancelling an incident does not mean that it has been solved, but to clean up incidents that should not have been
opened.
11
Process Overview
State: New
12
When an incident is first created, it is in a state of New. This is where the incident ticket is opened, and all known
information about the symptoms experienced is captured. Capturing sufficient and relevant details at this stage is
very important; it will aid in diagnosis if the incident requires escalation. A description of the incident in the caller’s
own words should be recorded so that future contact with the caller can be made on their terms. It will be
automatically assigned to the Service Desk as the front line to review anything coming into the IT department for
action.
The recommended mandatory fields are:
 Caller
 Service
 Service Offering
 Configuration item
 Contact type
 Impact
 Urgency
 Priority – this is automatically populated from the Impact + Urgency fields
 Assignment group
 Short description
 Description
If the incident is raised through self-service it would only be expected for the end user to provide limited details.
Most of the fields entered by an agent would not be known or understood by the end user. It is recommended that
self-service is structured to provide actionable information by the agent. For further information on self-service, see
How to achieve actionable information from a self-service Incident Management record producer .
Where the incident is raised through email then the quality of the details provided can vary considerably therefore
email should be considered as a channel of last resort.
13
Process Critical Attributes
There are several attributes captured in an incident that drive aspects of the process.
Establishing Priority
Incident prioritization typically drives the timeframe associated with the handling of the incident and the time to
resolution. This will impact the Service Level Agreements that are associated with the incident. Priority is calculated
through a combination of Impact and Urgency. Process owners must clearly define the different levels of impact,
urgency, and response/restoration timeframes associated with the resulting priorities. This will be used to define
SLAs and ensure consistency across the process.
Impact is the effect that an incident has on business. For example, if the incident only impacts a single employee,
the impact is low compared to 500,000 paying customers with social media accounts.
1 - Critical Large number of staff or customer will be affected (threshold tbd)

Financial impact of the incident is likely to exceed (threshold tbd)
2 - High Moderate number of staff or customer will be affected (threshold tbd)
Financial impact of the incident is likely to exceed (threshold tbd) and be below (threshold tbd)
3 - Medium Small number of staff or customer will be affected (threshold tbd)
Financial impact of the incident is likely to be less than (threshold tbd)
Urgency is the extent to which the incident's resolution can bear delay.
1 - Critical Service is down and no workaround is available

Work cannot be complete by staff
2 - High Service is affected or degraded though the service is still available and/or workaround provided
Impact caused by the incident increased considerably over time
3 - Medium Service if not affected and available for use
Impact caused by the incident marginally increases over time
Work that cannot be completed by staff is not time sensitive.
14
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

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

3 - Low
3 - Medium 4 - Low 4 - Low
It is possible to automatically establish the priority of the incident based on the CI identified in the incident record.
With this technique, the business criticality value of the CI is used to determine the priority of the incident. For
example, an online banking service would be considered critical to a financial organization. If this CI is related to
the incident the priority can be automatically set to Critical as a result. This ensures a more accurate and consistent
prioritization of incidents, as determining impact and urgency can be a subjective call.
15
Categories/Business Services & CIs
The CMDB (CI fields) is also used to identify what is impacted by the incident. It offers significantly enhanced data
than what could be made available in a choice list. The Category field should be replaced by the Business service
and Configuration item field/related lists to maximize the benefits of the platform and to allow better interaction
across the various ITSM processes. Business Service CI is available across all ITSM processes and, therefore, must
be related to an incident to provide true insight into the performance and health of the service. By using categories,
the data is limited to the incident management process only and does not provide value beyond that.
See article How to configure incident management to align with CSDM; a leading practice guide .
The Category field is intended to identify what is being impacted by the incident; however, it is only recommended
to be used where the CMDB (Configuration Management Databases) is not yet in use or is extremely immature.
Proper categorization of incidents supports an easy classification and, therefore, a correct routing to the right team.
Furthermore, a report of incidents based on the categorization can help structure the support in a more efficient
manner.
Often, too many categories are created. When more categories are offered to the user, the less likely it is they will
select the correct one – resulting in inaccurate data. Categorization also needs to be analyzed using auto-assignment.
Common categorization pitfalls
 Making categories too granular – More categories do not mean better data. Agents will categorize incidents
incorrectly because they won’t necessarily search for the correct category.
 Adding an “Other” category – If agents cannot find the correct category, they often put it in the “Other”
bucket. For example, if 30% of the incidents in the “Other” category are password resets, then “Password
Resets” must be a specific category.
16
Examples of Category / Sub-categories that have been used across a range of customers.
Category Subcategory
Access to a file/folder/location
Application Access
Email Access
Access Control
Network/Internet Access
Remote Access
Other
Authentication
Backup/Recovery
Data Integrity
Data
Database Performance/Sizing
Visibility/Encryption
Other
AC/Heat Fault
Building Access
Facilities Data Center Access
Power Fault
Other
Backup/Recovery
Broken component
Configuration
Hardware/ Software Defect/Error Message
Performance Issues/Delayed Response
Virus
Other
DHCP
DNS
Hard Wired Connectivity
Network IP Conflict
VPN Connectivity
Wireless Connectivity
Other
Denial of Service (DoS)
Improper Usage
Malicious Code
Security
Scans/Probes/Attempted Access
Unauthorized Access
Other
Audio Quality
Broken Component
Telephony Inbound Calls/Dead Air
Outbound Dialling/Fast Busy
Other
17
Incident Assignment
The Service Desk Agent may already be aware of the correct group to assign the incident to and, at this point, would
reassign it to that group. If automated assignment is in place, this will also occur here, usually once the Business
service or CI is populated. The new assignment group will review the incident in their work list and assign it to an
individual to focus on. Once that individual begins working on the incident, they will manually set the state field to
In Progress. This will then stop the clock on any response SLAs that may be running as this is responding.
Alternatively, the Agent may need to begin some investigation and triage. At this point, they will assign the incident
to themselves using the Assigned to field and set the state field to In Progress.
It is mandatory to assign an individual to the incident so that it can move to In Progress. This is so that anyone
wanting to get an update/discuss the issue will know who is responsible for it.
Implementation Insight:
Each agent has access to the queue of incidents to be worked on. In order to help the agent decide which incident
needs to be worked on first, it is important to set the correct prioritization rules in the queue, visualize the relative
fields, and properly report the incident backlog. Furthermore, idle time should be managed so that incidents are
continually processed.
See article: How to optimize work assignment over time in ServiceNow with 6 out-of-box capabilities
State: In Progress
The incident is now actively being worked on. In Progress state covers many different activities that are required to
resolve the issue. This will begin with investigation and triaging by the Assigned-to individual to establish what the
cause might be and/or how to fix it. It is possible to use the Contextual Search feature to display knowledge articles
within the incident that match or are like the short description entered. This allows the Assigned individual to easily
locate any published information that may provide them with help in resolving the issue. They may also refer to
similar incidents and problem records.
The individual may subsequently reassign the incident to another assignment group or individual if they discover a
better-suited group/individual to deal with the issue. This is done by updating the Assignment group and assigned to
18
fields and may involve passing the incident to 2nd or 3rd line subject matter experts. An email notification will be
sent to the new assignees to inform them they are now responsible.
It is possible for the incident to be reassigned multiple times while it is In Progress as different teams may need to be
involved. When reassigning an incident, it is mandatory to enter a Work note to explain why the incident is being
assigned to the new group or individual and what is expected of them. Reassigning an incident will not reset SLAs
attached to the incident unless the SLA is specifically tracking reassignment only. Therefore, if an SLA only has 1
hour remaining before it will breach and is then reassigned the new team will still only have 1 hour before the SLA
will breach.
Throughout this time the Work notes field is used to make journal style updates to the incident capturing what
actions have been taken and what has been learnt. If an update needs to be provided to the original caller this can be
done using the Additional Comments field.
When a fix is identified by the investigation, the assigned to individual will apply the fix to resolve the issue. This
may be in the form of a workaround rather than a permanent solution. A change request is raised to apply the fix,
and this is related to the incident in the Change Request field. If the incident is purely waiting for the change to be
implemented and no other activities are occurring, the State field can be changed to On Hold with an On Hold
reason of Awaiting Change.
During investigation, it may be discovered that a change was the cause of the issue. If this is the case, the change in
question can be related to the incident using the Caused by Change field.
Once the fix or workaround is applied, the Assigned to individual will test to see if the issue is resolved. If they
believe it is, they will change the state field to Resolved or click the Resolve button.
State: On Hold
The On Hold state is used to indicate where an incident is not yet resolved but is temporarily not being worked while
waiting for further action to occur outside of the control of the Assigned to individual.
There is a separate On Hold reason field to determine why the incident is on hold. This is a choice list so that
process owners can only include those reasons which they determine legitimate for pausing an incident therefore
guiding the users of the process to follow it correctly.
The incident is put into On Hold state by changing the State field. The On Hold reason field becomes mandatory at
this point with the following choices:
 Awaiting Caller
 Awaiting Change
 Awaiting Problem
 Awaiting Vendor
ServiceNow recommends removing Awaiting Problem from the choices. Resolving an incident should never be
dependent on a problem.
The Service Level Management product will make heavy use of this state since putting something on hold (Awaiting
Caller) will typically act as the pause condition for all SLAs.
State: Resolved
19
To move the State to Resolved, the Assigned to individual will need to give some further details to explain what the
problem was and how it was fixed. The mandatory fields are:
 Resolution code
 Resolution notes
The Resolution codes field is a choice list focused on the nature of the resolution provided, for example, whether a
workaround was provided or a permanent fix. They are not intended to explain how the incident was resolved.
Resolution notes is a free text field intended to describe what the issue was and how it was resolved. This is
deliberately not held as a category or choice list solution. Experience shows that there tends to be many possible
codes. These would have to be filtered based on the CI related to the incident. If this filter was not applied, then the
resolver would have so many options for the choices would be overwhelming, and the chance of correct data being
selected becomes significantly reduced resulting in the data no longer offering value.
The effort involved in maintaining this level of related data is usually high and the maintenance costs invariably
outweigh the business benefits of being able to report on it.
Requiring codes to track what the issue was and how it was fixed should only be done where there is a clear
business benefit to be achieved.
Once the resolution information is provided the Caller is notified that the Assigned to individual believes they have
resolved the issue.
The Caller has 7 days to disagree with this. They will be sent an email notification to advise them which provides a
link back to the incident if they disagree. In the incident they will click the Reopen Incident button which will
require them to enter an Additional comment explaining why they believe the incident is not yet resolved. This will
set the State field back to In Progress and clear the Resolution code and notes. The Assigned to individual will
receive a notification containing the Additional comments from the Caller.
If the Caller does not contest the resolution, they do not need to take any action. The incident will remain as
Resolved for 7 days. After that time, the State field is automatically updated to Closed.
State: Closed
20
No activities take place at this state. Should the incident reoccur a new Incident record must be raised. Once an
incident is closed, it cannot be reopened.
State: Canceled
There are very few scenarios where an incident is genuinely canceled. This will only occur when an incident was
raised in error, usually prematurely before realizing there is no real issue.
Incident Tasks and Parent / Child incidents

Incident tasks are available as part of the overall incident management process. An incident can have multiple
incident tasks assigned and created to conduct a specific action or set of actions that need to be performed in
response to an incident. Incident tasks can help break down the incident management process into smaller,
manageable tasks and allow the activities to be assigned to specific groups.
Parent/child incidents refer to a relationship between two or more incidents, where one incident (the parent) is seen
as the main or overarching issue, and other incidents (the children) are related to, or caused by, the parent incident.
This relationship can help incident managers understand the relationships between incidents. Within ServiceNow the
resolution of a parent incident can be cascaded to all the child incidents.
The two approaches can be used together or neither deployed. Operational visibility in both cases is important to
ensure that the work is done in a timely manner and not obscured by the hierarchical relationships.
21
Parent and Child Incidents
Where an incident is causing a widespread impact, this will be evident with several records being raised by different
Callers for the same issue. Although these incidents are reporting the same thing and might be considered duplicates
of each other it is good to capture each instance where the impact has been experienced so that the size of impact
can be more easily determined.
The downside of having many incidents logged with the same issue is that they will all need to be updated as the
incident is diagnosed and resolved. This can be easily handled by designating one incident as the parent and relating
all other incidents to this parent via the Child Incidents related list. When Work notes or Additional comments are
added to the parent, they will automatically copy to all related child incidents. In addition, when the parent is
resolved the child incidents will also be resolved and the closure information copied over. Incidents are related in
this manner using the Parent incident field or Child incidents related list.
Handling Ad Hoc Questions/Help

Where a caller has an ad hoc question or request for help that does not involve an issue this may be captured using
the Interaction feature. This allows the question to be handled without having to log an incident or create a service
request for the purpose.
It is not recommended to create a catalog item in the Service Catalog for this purpose since the structure of requests,
requested items and catalog tasks is over complex for this need. If the process owner does not wish to use the
Interaction feature, an incident record is used to capture this interaction. If the Category field is in use the Inquiry /
Help choice should be selected to distinguish this from a true incident. If the Category field is not in use a new field
will be required to determine this.
22
Incident Escalations
Functional escalation
Functional escalation involves moving the incident to a different team or individual with the necessary expertise and
skills to handle it. This type of escalation is primarily based on the technical requirements of the incident.
Hierarchical escalation
Hierarchical escalation involves moving the incident up the management chain within the organization. This type of
escalation is primarily based on the urgency, impact, or visibility of the incident, rather than the technical
requirements.
This can occur when, for example

 The incident is requested to be resolved in a shorter period of time than the MTTR SLA for that priority
 Incident has exceeded its SLA and the requirement is to resolve as soon as possible
Functional Escalation Hierarchical Escalation

Reason for Escalation Technical expertise and capability Urgency, impact, and visibility
When it occurs Lack of knowledge/resources at current Unresolved incidents, high-impact
level scenarios
Movement Lateral or vertical (within support Vertical (up the management chain)
groups)
Focus Technical resolution Management intervention and resource
allocation
Example Escalating to a specialized tech team Escalating to higher management
levels
23
24

Incident Management - Design

Uploaded by

Copyright:

Available Formats

Incident Management - Design

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Incident Management - Design

Uploaded by

Copyright:

Available Formats

ITSM Incident Management

Principles and Basic Concepts

Responsibility  Bringing incidents to the attention of the Service Desk

Role Name Service Desk Agent (1st Line)

Responsibility  Recording, ownership, monitoring, tracking, and communication about incidents

Role Name Incident Admin

ServiceNow Role The incident_manager role is required for incident administration.

Responsibility  Defining the overall mission of the process

Group Name Service Desk Group(s) (1st line)

ServiceNow Role ITIL

Group Name IT Support Team (2nd/3rd line)

ServiceNow Role ITIL

Some examples of assignment groups are:

Incident State Model

1 - Critical Large number of staff or customer will be affected (threshold tbd)

1 - Critical Service is down and no workaround is available

1 - High 2 – Medium 3 - Low

Priority Priority Priority

Priority Priority Priority

Priority Priority Priority

Incident Tasks and Parent / Child incidents

Handling Ad Hoc Questions/Help

This can occur when, for example

Functional Escalation Hierarchical Escalation

You might also like