Revision

History

Ver # Date
0.1

10-1216

Author
NSS

Reviewed
by

Approved
by

Changes made /
Remarks
Initial draft

Contents:
1

Introduction............................................................................................................. 4
1.1

Objectives......................................................................................................... 4

1.2

Purpose............................................................................................................. 4

1.3

Goal:.................................................................................................................. 4

1.4

General Purpose Scope:.................................................................................... 5

1.4.1

Exclusions................................................................................................... 5

1.4.2

Inputs and Outputs..................................................................................... 5

1.4.3

Metrics........................................................................................................ 5

1.5

Impact............................................................................................................... 6

1.6

Priority............................................................................................................... 6

1.7

Response........................................................................................................... 6

1.8

Resolution.......................................................................................................... 6

1.9

Service Agreement............................................................................................ 6

1.10 Service Level Agreement................................................................................... 6

1.11 Service Level Target.......................................................................................... 7
1.12 Severity............................................................................................................. 7
2

Key Definitions and Terms:...................................................................................... 8

Roles & Responsibilities......................................................................................... 10

3.1

Incident Management Process Owner.............................................................10

3.2

Incident Management Process Manager..........................................................11

3.3

Service Desk Technician.................................................................................. 13

3.4

Service Provider Group Incident Manager.......................................................14

3.5

Service Provider Group Incident Technician.....................................................16

3.6

User................................................................................................................. 16

Incident Categorization, Target Times, Prioritization, and Escalation.....................18

4.1

Categorization................................................................................................. 18

4.2

Priority Determination..................................................................................... 18

4.3

Target Times.................................................................................................... 20

Incident Management High Level Process Descriptions.........................................20

Incident Management Service Desk Process Flow - (Activity 1.0)..........................21

6.1

Incident Management Service Desk Process - Activity Descriptions................22

6.2
7

Incident Management Service Desk Process RACI Matrix................................27

Incident Management Service Provider Group Process Flow- (Activity 2.0)...........29

7.1

Activity Descriptions........................................................................................ 29

7.2

Incident Management Service Provider Group Process RACI Matrix................36

Incident Management Verify, Document & Close Process Flow -- (Activity 3.0).....37
8.1

Activity Descriptions........................................................................................ 38

8.2

Incident Management Verification, Document and Closure Process RACI Matrix

44

8.3

Reports and Meetings...................................................................................... 45

8.3.1

Reports -Service Interruptions...................................................................45

8.3.2

Metrics...................................................................................................... 45

8.3.3

Meetings................................................................................................... 45

1 Introduction
An incident is defined as, an unplanned interruption to an IT Service or reduction in
the quality of an IT service. This includes any events that disrupts or could disrupt a
service.
The goal of the incident management process is to restore a normal service operation
as quickly as possible and to minimize the impact on business operations, thus
ensuring that the best possible levels of service quality and availability are
maintained. 'Normal service operation' is defined here as service operation within
service-level agreement (SLA).

1.1 Objectives
Incident Management is the process responsible for managing the lifecycle of all
Incidents irrespective of their origination.

Restore normal service operation as quickly as possible

Minimize the adverse impact on business operations
Ensure that agreed levels of service quality are maintained

1.2 Purpose
The purpose of this document is to describe the incident process. The process
provides a consistent method to be followed for incident management across the
enterprise. It includes Incident Management goals, objectives, scope, benefits, key
terms, roles, responsibilities, authority, process diagrams and associated activity
descriptions.
The content within this general overview is based on the best practices of the ITIL
framework.

1.3 Goal:
The goals for the Incident Management process are to:

I
Restore normal service operation as quickly as possible
Minimize the adverse impact on business operations
Ensure that agreed levels of service quality are maintained
Identify MIM

1.4 General Purpose Scope:

Any event which disrupts, or which could disrupt, a service, including those:

Reported directly by end users

Reported and/or logged by technical staff via web interface
Detected by Event Management- Delete Event Management
Reported and/or logged by emails

The Incident Management Process, encompasses all IT service providers, internal and
third parties, reporting, recording or working on an Incident.
All Incident Management activities should be implemented in full, operated as
implemented, measured and improved as necessary.

1.4.1 Exclusions
Request fulfillment, i.e., Service Requests and Service Catalog Requests are not
handled by this process.
Root cause analysis of original cause of incident is not handled by this process. Refer
to Problem Management. The need for restoration of normal service supersedes the
need to find the root cause of the incident. The process is considered complete once
normal service is restored.

1.4.2 Inputs and Outputs

Input
Incident (verbal or written)

From
Customer

Categorization Tables

Functional Groups

Assignment Rules

Functional Groups

Output

To

Standard notification to the customer

when case is closed

Customer.

1.4.3 Metrics
Metric

Purpose

Process tracking metrics

To determine if incidents are being

processed in reasonable time frame,
frequency of specific types of incidents,
and determine where bottlenecks exist.

# of incidents by type, status, and

customer

1.5 Impact
Impact is determined by how many personnel or functions are affected. There are
three grades of impact:

3 - Low One or two personnel. Service is degraded but still operating within

SLA specifications
2 - Medium Multiple personnel in one physical location. Service is degraded
and still functional but not operating within SLA specifications. It appears the

cause of the incident falls across multiple service provider groups

1 - High All users of a specific service. Personnel from multiple agencies are
affected. Public facing service is unavailable

The impact of an incident will be used in determining the priority for resolution.

1.6 Priority
Priority is determined by utilizing a combination of the incidents impact and severity.
For a full explanation of the determination of priority refer to the paragraph titled
Priority Determination.

1.7 Response
Time elapsed between the time the incident is reported and the time it is assigned to
an individual for resolution.

1.8 Resolution
Service is restored to a point where the customer can perform their job. In some
cases, this may only be a work around solution until the root cause of the incident is
identified and corrected.

1.9 Service Agreement

A Service Agreement is a general agreement outlining services to be provided, as well
as costs of services and how they are to be billed. A service agreement may be
initiated between the organization and another agency or vendor entity. A service
agreement is distinguished from a Service Level Agreement in that there are no
ongoing service level targets identified in a Service Agreement.

1.10 Service Level Agreement

Often referred to as the SLA, the Service Level Agreement is the agreement between
organization and the customer outlining services to be provided, and operational
support levels as well as costs of services and how they are to be billed.

1.11 Service Level Target

Service Level Target is a commitment that is documented in a Service Level
Agreement. Service Level Targets are based on Service Level Requirements, and are
needed to ensure that the IT Service continues to meet the original Service Level
Requirements.

1.12 Severity
Severity is determined by how much the user is restricted from performing their work.
There are three grades of severity:

Low - Issue prevents the user from performing a portion of their duties.
Medium - Issue prevents the user from performing critical time sensitive
functions
1 - High - Service or major portion of a service is unavailable

The severity of an incident will be used in determining the priority for resolution.

2 Key Definitions and Terms:

Term
Priority

Definition
A category used to identify the relative importance of an Incident,
Problem or Change. Priority is based on impact and urgency and is used
to identify required times for actions to be taken. For example, the SLA
may state that Priority 2 Incidents must be resolved within 12 hours.

Priority 1

The highest category of impact for an Incident which causes significant

Incident

disruption to the business. A separate procedure with shorter

timescales and greater urgency should be used to handle Major

Problem
Quality

Incidents.
The cause of one or more incidents.
Optional departmental process for ensuring a desired level of customer

Assuranc

service. This process is defined by the departments that choose to

e (QA)
RACI

review tickets prior to closure.

A responsibility matrix showing who is Responsible, Accountable,

Matrix

Consulted and Informed for each activity that is part of the Incident

Role

Management process.
A set of responsibilities, activities and authorities granted to a person or
team. A role is defined in a process. One person or team may have
multiple roles; for example, the roles of Configuration Manager and

Service

Change Manager may be carried out by a single person.

The Single Point of Contact between the Service Provider and the users.

Desk

A typical Service Desk manages Incidents and Service Requests and

Severity

also handles communication with the users.

A measure of how long it will be until an Incident, Problem or Change
has a significant impact on the business. For example, a high Impact
Incident may have low urgency, if the impact will not affect the
business until the end of the financial year. Impact and urgency are

Service

used to assign Priority.

Line staff who are the subject matter experts for assessing, planning

Desk

and monitoring Incident Management for their functional organization

and specific technology platform. They function as contact people
between the different departments for a specific process and may be
responsible for the design of processes within their own departments.

Service

More in-depth technical support than Service Desk. Service Provider

Provider

Group support personnel may be more experienced or knowledgeable

Group

on a particular product or service. Additionally, Service Provider Group

may be able to provide onsite troubleshooting and/or resolution.
Specialized departments (i.e. Networks, Servers, Video) will provide

User

Service Provider Group Support in their respective areas of expertise

Someone who uses the IT service on a day-to-day basis. Sometimes
informally referred to as the customer.

3 Roles & Responsibilities

A role refers to a set of connected behaviors or actions that are performed by a
person, team or group in a specific context. Process roles are defined by the set of
responsibilities, activities and authorities granted to the designated person, team or
group. Some process roles may be full-time jobs while others are a portion of a job.
One person or team may have multiple roles across multiple processes. Caution is
given to combining roles for a person, team or group where separation of duties is
required. For example, there is a conflict of interest when a software developer is also
the independent tester for his or her own work.
Regardless of the scope, role responsibilities should be agreed by management and
included in yearly objectives. Once roles are assigned, the assignees must be
empowered to execute the role activities and given the appropriate authority for
holding other people accountable.
All roles and designated person(s), team(s), or group(s) should be clearly
communicated across the organization. This should encourage or improve
collaboration and cooperation for cross-functional process activities.

3.1 Incident Management Process Owner

Profile

The person fulfilling this role is responsible for ensuring that

the process is being performed according to the agreed and
documented process and is meeting the aims of the process
definition.
There will be one, and only one, Incident Management

Responsibi
lities

Process Owner.
Assist with and ultimately be responsible for the process
design
Define appropriate policies and standards to be employed
throughout the process
Define and review Key Performance Indicators to evaluate
the effectiveness and efficiency of the process and design
reporting specifications
Ensure that quality reports are produced, distributed and

utilized
Periodically audit the process to ensure compliance to policy
and standards
Address any issues with the running of the process
Review opportunities for process enhancements and for
improving the efficiency and effectiveness of the process
Ensure that all relevant staff have the required technical and
business understanding, knowledge and training in the
process and are aware of their role in the process
Ensure that the process, roles, responsibilities and
documentation are regularly reviewed and audited
Interface with the line management, ensuring that the
process receives the needed staff resources
Provide input to the on-going Service Improvement Program
Communicate process information or changes, as
appropriate, to ensure awareness
Review integration issues between the various processes
Integrate the process into the line organization
Promote the Service Management vision to top-level/senior
management
Function as a point of escalation when required
Ensure that there is optimal fit between people, process and
technology/tool
Ensure that the Incident Management process is Fit for
Purpose
Attend top-level management meetings to assess and
represent the Incident Management Requirements and
provide Management Information

3.2 Incident Management Process Manager

Profile

Service Desk Technicians are the line staff who are the
subject matter experts for assessing, planning and
monitoring Incident Management for their functional

organization and/or specific technology platform. They

function as initial contact between those reporting incidents
and the IT organization.
Technicians residing in departments where Service Provider
Group support is commonly provided may function as
Service Desk support. In this case the Technician is the initial

Responsibi
lities

contact with those reporting the incident.

Promote the Incident Management process
Ensure the Incident Management process is used correctly
Provide management and other processes with strategic
decision making information related to Incidents and
potential Problems
Ensure Incident Management KPIs are met
Ensure that the Incident Management process operates
effectively and efficiently through 1st, 2nd, and 3rd line
support and Third Party organizations
Ensure Incident Management Staff are empowered in their
jobs
Maximize the fit between people, process and technology
Provide the resolution of Incidents in a proper and timely
manner as it is the end-responsibility of Incident
Management. Ensure that Incidents are resolved in a proper
and timely manner and the resolutions adhere to objectives
set forth in Service Level Agreements
Participate with the Incident Management Process Owner in
developing and maintaining the Incident Management
Process, policies and procedures
Drive the efficiency and effectiveness of the Incident
Management Process
Produce Management Information
Monitor the Incident Management process, using qualitative
and quantitative Key Performance Indicators and make
recommendations for improvement

Play a key role in developing and maintaining the Incident

Management systems.
Manage Major Incidents
Escalate to Line Management if Service Levels are
threatened to be breached.
Identify training requirements of support staff and ensure
that proper training is provided to meet the requirements.
Identify opportunities for improving the tools used.
Audit the Incident Management process
Escalate to Management and the Incident Management
Process
Owner in the event of a conflict between process and
Management
Promote the Service Desk with the end-user community,
through the maintenance of a web-page, info mails, bulletins
and training Service Desk staff in communication skills,
where needed.
Provide Service Desk staff with appropriate information to
enable them to perform their function effectively. This
includes process information, technical knowledge, record
allocation information, and access to Known Error
information

3.3 Service Desk Technician

Service Desk Technicians are the line staff who are the

Profile

subject matter experts for assessing, planning and

monitoring Incident Management for their functional
organization and/or specific technology platform. They
function as initial contact between those reporting incidents
and the IT organization.
Technicians residing in departments where Service Provider
Group support is commonly provided may function as
Service Desk support. In this case the Technician is the initial

contact with those reporting

Responsibi
lities

Log relevant Incidents

Categorize and prioritize incidents
Provide first-line investigation and diagnosis
Resolve those Incidents they are able to
Escalate incidents that cannot resolve within agreed
timescales
Close all assigned and resolved Incidents
Communicate with users; keep them informed of incident
progress, notifying them of impending changes or agreed
outages, etc.
Take ownership of assigned Incidents
Understand and use the process, procedures, work
instructions, policies, required documentation and tools

3.4 Service Provider Group Incident Manager

Profile

Incident Managers are the line staff who are responsible for the
planning and monitoring of the Incident Management process and
associated records. They function as contact people between the
different departments for a specific process and may be responsible
for the design of processes within their own departments.
In general, the Service Provider Group Incident Manager:
May be a department lead or a person identified as an Incident
Manager for a length of time.
Understands how the specific technology fits in with the overall IT
service and Service Lifecycle
Must be an effective communicator. Is a member of a department
who is able to combine daily departmental activities with the

Responsibil
ities

coordination role
Managing ownership of Incident records while providing monitoring
and tracking of Incidents for their department
Validates, accepts and assigns Incident records to Service Provider
Group Incident Technicians
Closing all assigned and resolved Incidents
Determine whether an Incident record requires special reporting
Understand the process, procedures, work instructions, policies,
required documentation and tools
Use the process, procedures, work instructions, policies, required
documentation and tools as designed
Produce usage and performance data for his or her specific

3.5 Service Provider Group Incident Technician

Service Provider Group Incident Technicians provide more in-

Profile

depth technical support than Service Desk Technicians. Service

Provider Group Technicians may be more experienced or
knowledgeable on a particular product or service. Additionally,
Service Provider Group Technicians may be able to provide
onsite troubleshooting and/or resolution. Service Provider Group
Technicians normally reside in specialized departments, such as

Responsibilit
ies

Networks, Servers or Video, and will provide support in their

If no Service Provider Group Incident Manager role is identified,
take ownership and provide monitoring and tracking of all
Incidents
If no Service Provider Group Incident Manager role is identified,
validates, accepts and assigns Incident records
Communication with users keeping them informed of incident
progress, notifying them of impending changes, confirming
Incident resolution or agreed outages, etc.
Closing all assigned and resolved Incidents
Initiate the Change Management process if an Incident requires
a
Change to resolve
Request interdepartmental work if required to resolve an
Incident

3.6 User

Profile

Any person who reports an incident or requests a change. This

person may come from many of the ITSM roles to included, but not
limited to: User, Service Owner, Service Provider, or Service Desk/

Responsibil
ities

Service Provider Group Technician.

Provides the input into the Incident Management Process
Reports incidents when they occur
Uses the Service Desk, contacts a department directly, or opens a
ticket directly in the ITSM Tool

4 Incident Categorization, Target Times, Prioritization, and

Escalation
In order to adequately determine if SLAs are met, it will be necessary to correctly
categorize and prioritize incidents quickly.

4.1 Categorization
The goals of proper categorization are:

Identify Service impacted and appropriate SLA and escalation timelines

Indicate what support groups need to be involved

Provide meaningful metrics on system reliability

For each incident the specific service (as listed in the published Service Catalog) will
be identified. It is critical to establish with the user the specific area of the service
being provided. For example, if its PeopleSoft, is it Financial, Human Resources, or
another area? If its PeopleSoft Financials, is it for General Ledger, Accounts Payable,
etc.? Identifying the service properly establishes the appropriate Service Level
Agreement and relevant Service Level Targets.
In addition, the severity and impact of the incident need to also be established. All
incidents are important to the user, but incidents that affect large groups of personnel
or mission critical functions need to be addressed before those affecting 1 or 2 people.
Does the incident cause a work stoppage for the user or do they have other means of
performing their job? An example would be a broken link on a web page is an incident
but if there is another navigation path to the desired page, the incidents severity
would be low because the user can still perform the needed function.
The incident may create a work stoppage for only one person but the impact is far
greater because it is a critical function. An example of this scenario would be the
person processing payroll having an issue which prevents the payroll from processing.
The impact affects many more personnel than just the user.

4.2 Priority Determination

The priority given to an incident that will determine how quickly it is scheduled for
resolution will be set depending upon a combination of the incident severity and
impact.

Incident Priority

Severity
3 - Low

2 - Medium

1 - High

Issue prevents

Issue prevents

Service or

the user from

the user from

major

performing a

performing

portion of a

portion of their

critical time

service is

duties.

sensitive

unavailable

functions
Low 3 -

Impact

One or two

1 - High
Medium 2 -

personnel

3 - Low

3 - Low

2 - Medium

2 - Medium

2 - Medium

1 - High

1 - High

1 - High

1 - High

Multiple personnel
in one physical
location
All users of a
specific service
Personnel from
multiple agencies
are affected

4.3 Target Times

Incident support for existing services is provided 24 hours per day, 7 days per week,
and 365 days per year. Following are the current targets for response and resolution
for incidents based upon priority.
Priority

Target
Response

Resolve

3 - Low

90% - 24 hours

90% - 7 days*

2 - Medium

90% - 2 hours

90% - 4 hours

1 - High

95% - 15 minutes

90% - 2 hours

5 Incident Management High Level Process Descriptions

Activity

Description

1.0
Incident
Management
Service Desk

The process describes the activities that take place to resolve

incidents within Service Desk, which may be either the Support
Center or a department that has been contacted directly. If Service
Provider Group is contacted directly, they will act on behalf of
Service Desk, following the process through to Service Provider
Group, if the record requires escalation. Interactions which are
determined to be anything other than an incident are outside the

2.0 Incident

scope of this process.

Incidents that are unable to be resolved at Service Desk are

Management

escalated to second level support (Service Provider Group).

Service
Provider Group
3.0 Incident
This process is used by both Service Desk and Service Provider
Management

Group to ensure all incidents are verified, documented and closed

Verify,

consistently.

Document &

6 Incident Management Service Desk Process Flow (Activity 1.0)

6.1 Incident Management Service Desk Process - Activity Descriptions

1.1
Purpose

Log, Categorize and Prioritize Incident

The incident is logged, prioritized, and categorized in
the ITSM tool to enable tracking and monitoring
through resolution of the incident

Requirement Statement All incidents are tracked in the ITSM tool

Inputs
Procedure or Work
Instruction
Steps

Phone, email, self-service notification

Incident is logged in the ITSM tool
Include incident details
Incident is categorized based on internal agreement
Incident is prioritized based on impact and severity

Outputs
Metric

Incident record
Total number of incidents reported
Number of incidents by category
Number of incidents by priority

1.2
Purpose

Troubleshoot Using Knowledge Base

Resolve incident quickly, minimizing impact to the

Requirement Statement To
university
resolve incident at initial point of contact
Inputs
Procedure or Work
Instruction
Steps

Incident record and available knowledge base articles

Has another user called with a similar incident?
Use available knowledge to resolve the incident
Attempt to resolve the incident collaboratively with
User

Outputs

Attempt to resolve incident using remote assistance

Updated Incident record
New or updated knowledge base record

Metric

Time to resolve incident

Incidents resolved using remote assistance
Incidents resolved using knowledge base

D.1.3

Related to Open Incident?

Purpose

Service Desk combines similar service requests into

one incident. The purpose of relating records is to
minimize the impact to Service Provider Group

Decision Logic

resources.
Yes
Go to 1.4 Relate to existing record
No Go to D.1.6 Resolved at Service Desk?

1.4
Purpose

Relate to Existing Record

To link similar incidents together under one parent
incident
record. When parent incident is closed, users are

based
on notification
method
step 1.1record.
Requirement Statement notified
All duplicate
incidents
will be relate
toin
a parent
Related
service requests should be combined together to
Inputs
Procedure or Work
Instruction
Steps

minimize
the number of incidents being worked on.
Incident record
Relate new incident to open incident using ITSM tool
referencing ERD managed by Incident Manager
If relationship error is made (not related appropriately
or mis-assigned) first line support will break relation
and modify parent/child relationships

Outputs
Metric

Updated Incident record

Number of related requests to one incident
Number of incidents re-opened

1.5

Update Priority

Purpose

Multiple reports of a similar incident may reflect a

larger scope of
service degradation. Incident resolution may

Requirement Statement Incidents

will haveresources.
an assigned priority allowing
require additional
appropriate
Inputs
Procedure or Work
Instruction
Steps

resources to be directed towards resolution.

Multiple incident records, ERD
Update priority of parent record
o Priority based on impact and severity
Incident Manager communicates with the
appropriate Incident Manager

Outputs

Updated incident record

Metric

Number of high priority incidents

D.1.6

Resolved at Service Desk?

Purpose

Determine whether escalation is needed

Decision Logic

Yes Go to Verify Document and Close process

No Go to 1.7 Escalate to Service Provider Group

1.7
Purpose

Escalate to Service Provider Group

To escalate incidents to the correct Service Provider

Group group based on established service agreements

Requirement Statement Resolve all incidents at the lowest level possible
Inputs

Incident record

Procedure or Work
Instruction
Steps

Validate completeness of incident record per

established
service agreements
Reference service agreements to determine
Service Provider Group assignment group
Support Center may act as Service Provider Group

Outputs
Metric

in
supportincident
of specific
services
Updated
record
Number of incidents escalated
Number of incidents resolved at Service Desk

D.1.8
Purpose

Is This a High Priority?

High priority incidents require additional coordination
with Service Provider Group support

Decision Logic

Yes Go to 1.9 Confirm receipt with Incident Manager

No Go to Service Provider Group process

1.9
Purpose

Confirm Receipt with Incident Manager

Confirm Service Provider Group is aware of a high

priority incident ensuring resources are allocated to

Requirement Statement Incidents
an manner
assigned priority allowing
resolutionwill
in ahave
timely
Inputs

appropriate resources to be directed towards

Incident record
resolution.

Procedure or Work
Instruction

Service Desk technician confirms the Service Provider

Group Incident Manager (or designee) received the

Steps

incident record
Service Desk technician makes Service Provider
Group Incident Manager (or designee) aware of the
high priority incident
Service Desk technician passes along incident details
Updated incident record

Outputs
Metric

Number of incidents by priority

6.2 Incident Management Service Desk Process RACI Matrix

Activity

IM Process
Service
Service
Owner/Mana Desk
Provider
ger
Technician Group
Incident

1.1
Log, categorize and
prioritize incident

1.2
Troubleshoot using
knowledge base

D.1.1
Related to open
incident?

1.3
Relate to existing
record
1.4
Update priority

D.1.2
Resolved at Service
Desk?
1.5
Escalate to Service
Provider Group
D.1.3
Is this a high
priority?

Service
User
Provider
Group
Technician
C

1.6
Confirm receipt
with Incident
Manager

7 Incident Management Service Provider Group Process

Flow- (Activity 2.0)

7.1 Activity Descriptions

2.1
Purpose

Incident Manager Validates & Accepts

Verify that incident is assigned correctly, correct priority,
valid

Requirement

incident
and acknowledged
team of the
When validating
Incidents, itby
is assignment
the responsibility

Statement

Incident
Coordinator to determine if the ticket is assigned,

Inputs

prioritized and categorized correctly.

Incident Record
Related Record, Phone, Email, Alerts, Internal Service
Request, Self Service

Procedure or Work

Incident Manager reviewsReviews Incident for accuracy

Instruction

Incident Manager verifies assignment

Steps

Incident Manager acknowledges acceptance

Outputs
Metric

Update Incident
Updated
IncidentRecord
Record
Number of records incorrectly assigned Incidents
Number of tickets by priority
Time to assignment

2.2
Purpose

Departmental Reporting Per Priority

Depending on Departmental requirements, reporting
requirements might be different for various priorities.

Requirement Statement If special reporting is required, it will be done

according to
Inputs
Procedure or Work

Departmental
requirement
Incident Record
Determine whether the priority of this ticket requires

Instruction

special reporting. Follow procedures for special

Outputs

Updated
reportingIncident Record

Metric

2.3
Purpose

Number of tickets requiring special handling

Incident Manager Assigns Incident to Tech

The incident will be assigned to a technician to begin

Requirement Statement All

work
incidents will be assigned to a technician to begin
steps for
Inputs

Incident Record

Procedure or Work

Incident Manager assigns Incident to technician

Instruction Steps

Outputs

Updated Incident Record

2.4

Assessment and Initial Contact with User

Purpose

To begin assessment of the Incident and contact the

user,

them
that
request
is being worked
Requirement Statement informing
All incidents
must
betheir
assessed
to determine
steps on
to
resolution
and the user of the related record will be contacted
Inputs
Procedure or Work

notifying
them that work has begun
Incident Record
Technician will make initial contact with the user to

Instruction

confirm that their Incident is being addressed and

Steps

ask any preliminary questions that may be needed to

troubleshoot

Outputs

2.5
Purpose

Technician will conduct an initial assessment of the

Updated Incident Record

Use Existing Knowledge Base, Begin

Troubleshooting
Use
existing knowledge base, if applicable, to begin

troubleshooting
Requirement Statement Departmental knowledge bases assist technicians
with
Inputs
Procedure or Work

Incident Record
Technician will check the knowledgebase to see if

Instruction

there is

Steps

information available on the Incident

Outputs

Technician
will begin
troubleshooting
Updated Incident
Record

2.6
Purpose

Begin Incident Resolution

Incident Technician will take initial steps required to
complete the

Requirement Statement All Incidents must be resolved

Inputs
Procedure or Work

Incident Record
Incident Technician begins initial work required to

Instruction

resolve

Steps

the incident
If resolution requires assistance from a vendor or the
acquisition and/or replacement of hardware:
o Set incident record status accordingly
o Annotate record with case, ticket, order or RMA

Outputs

D.2.7
Purpose

number
Updated Incident Record

Incident Require a Change to resolve?

If a change is required to resolve the incident, a
related Change record must be created. For
additional information on Change Process, see

Decision Logic

2.8
Purpose

Change
Processrecord
Documentation.
Yes
GoManagement
to 2.8 Open related

Open Related Record

To inform a department that a Change will be needed
to resolve

Requirement Statement an
If aIncident
Change is required to resolve an Incident, a
related Change
Inputs

record is created to inform the department of the

Incident Record

Procedure or Work

Open a new/related Change record classified and

Instruction

prioritized appropriately

Steps

If the new/related Change record is a high priority,

confirm that the necessary department received the

Outputs
Metric

new/related
record.
Updated Incident
Record and Change Record
Number of Incidents that require a Change to
resolve

D.2.9
Purpose

Is Inter-Departmental work required?

If another department is needed to resolve an
Incident, the technician must create a related record.

Decision Logic

If yes, go to 2.8. If no, go to D.2.11

Yes Go to 2.11 Open related record
No Go to 2.13 Complete Incident resolution

2.10

Open Related Record

Purpose

Another internal group is required to assist in the

resolution of
the parent incident. In most cases this relation will be
in the form of an incident. Currently, some groups
use this to escalate related (child) changes as well as
related (child) incidents. As change management

within becomes more mature this will be used only

Requirement Statement If inter-departmental work is required, a related
record is created
Inputs
Procedure or Work

Incident Record
Open a new/related Incident record classified and

Instruction

prioritized appropriately

Steps

If the new/related Incident record is a high priority,

confirm that the necessary department received the

Outputs

2.11
Purpose

new/related
Incident
record.
Updated Incident
Record

Validate Inter-departmental Work

After related work is completed, either as a Change,
another

Incident or both, tasks will be confirmed by the

Requirement Statement If a department creates a related record, all tasks
completed by
Inputs
Procedure or Work

Incident Record
Ensure all related record have been closed and are

Instruction
Outputs

validated
Updated Incident Record

2.12

Complete Incident Resolution

Purpose

Incident Technician will take final steps required to

complete the

Incident resolution
Requirement Statement All Incidents must be resolved
Inputs
Incident Record
Procedure or Work
Incident Technician completes all work required to
Instruction

finalize resolution

Outputs

Updated Incident Record

7.2 Incident Management Service Provider Group Process RACI Matrix

Activity

2.1 Incident
Manager
Validates
&
2.2
Departmental
Reporting Per
Priority
2.3 Incident
Manager

IM Process
Owner/Man
ager

Service
Desk
Technici
an

Service
Provider
Group
Technician

Service
Provider
Group
Incident
Coordinato
R

C/I

2.4 Assessment
and
Initial Contact
2.5 Use Existing
Knowledge base,
Begin

2.6 Begin
Incident
Resolution
D.2.7 Incident
Require a
Change to
Resolve?
2.8 Open Related
Record

2.9 Assign
Appropriate
Priority to the
D.2.10 Is interdepartmental
work required?

2.11 Open
Related
Record
2.12 Validate
related
work
2.13 Complete
Incident
Resolution

C/I

C/I

Us
er

C/I

C/I

8 Incident Management Verify, Document & Close

Process Flow -- (Activity 3.0)

8.1 Activity Descriptions

3.1
Purpose

Primary Tech Verifies Resolution

Verification of incident resolution with the user

Requirement Statement Keeping with high standards of customer service, the

tech must
verify that the resolution applied fixed the issues the
Inputs
Procedure or Work

Incident
(specifically the resolution)
user wasrecord
experiencing.
Tech verifies fix applied resolves issue from techs

Instruction

end;

Steps

verification: did we apply the fix right?

Tech will contact the user
Tech confirms from users perspective that the

Outputs

resolution applied fixed the issue that caused them

User verification that the resolution fixed their issue

Metric

Length of time to resolution

3.2

Confirm with User Incident can be Closed

Purpose

Validation and Confirmation of incident closure with

Requirement Statement Keeping

the user with high standards of customer service, the
tech must
confirm that the user is comfortable with closing
Inputs
Procedure or Work

their ticket because their issue has been resolved.

Conversation with the user
After contacting the user via prefered method to

Instruction

validate

Steps

that the applied resolution worked; validation: did we

apply the right fix for the user?
Confirm with the user that the incident record is able
to be closed.

Outputs

User validates that it is alright to close their record. If

not, the

Metric
3.3
Purpose

record
be routed
through the Tier2 process
Lengthmust
of time
to closure
Update Knowledge Base and Incident Record
Update the knowledge base accessed by your
department or by

whichever applies.
Requirement Statement ,Sharing
knowledge of incidents occurring throughout
campus is a
helpful tool when detecting root causes. Whether a
departmental knowledge base or one knowledge
Inputs
Procedure or Work

base
of , the knowledge base must be updated
Stepsfor
to all
resolution
Update Incident Record with actions taken for 3.1

Instruction

and

Steps

user responses in 3.2 as well as any other responses

Outputs

that apply to the resolution of the incident

Updated Incident Record and Knowledge Base

D.3.4
Purpose

Is Review Required by the Incident Manager?

To provide a second pair of eyes, for additional
Quality

Decision Logic

Assurance
the
departmental
level. Incident
Yes Go to at
3.5
Tech
proposes closing
No Go to 3.11 Tech closes Incident record

3.5
Purpose

Tech Proposes Closing Incident

If additional Quality Assurance check is required,
another

Requirement Statement The technician believes that the incident was

resolved and
submits the incident record to management or the
Incident Manager for review that it meets
Inputs
Procedure or Work
Instruction
Steps

departmental standards and adheres to procedures.

The Incident Record
Tech changes status to Pending Closed
o Answer Optional QA Questions as appropriate
Submits the incident record for review to
management or

Outputs
Metric

Incident Incident
ManagerRecord
Updated
Number of additional Quality Assurance reviews by
department.

3.6
Purpose

Incident Manager Verifies Optional QA

Questions
Provides
a second opportunity to ensure that the
technician

completed the required steps

Requirement Statement Some departments may deem it necessary to use
additional
Quality Assurance steps. If so, ensure affirmative or
Inputs
Procedure or Work
Instruction
Steps

appropriate
context is provided in the incident
Incident Record
Verify the record contains acceptable outputs for
activity 3.5.
Here are some examples of Quality Assurance
questions:
What were the steps completed to resolve the
Incident?

Outputs
Metric

Updated Incident Record

Number of Incidents that fail Quality Assurance
Check

D.3.7
Purpose

Passes Quality Assurance Check?

It is the responsibility of the Incident Manager to
determine whether the incident passes the Quality

Decision Logic

Assurance Check.
Yes Go to 3.10 Incident Manager closes Incident
No Go to 3.8 Reassign record to tech

3.8
Purpose

Reassign Record to Tech

Assign to Technician to resolve outstanding QA Issues

Requirement Statement It is the responsibility of the Incident Manager to

assign the
Inputs
Procedure or Work
Instruction
Steps
Outputs

incident to a technician to resolve all outstanding

Incident Record
Incident Manager assigns Incident Record to
technician
Incident Manager communicates needed information
to be included in the incident records or appropriate
Updated Incident Record

Metric

Number of Incidents Failing Quality Assurance Check

3.9

Tech Resolves Quality Assurance Issue

Purpose

Technician to resolve outstanding Quality Assurance

Requirement Statement In
Issues
order to pass a Quality Assurance check, the
technician ensures
Inputs

Incident Record

Procedure or Work

Technician resolves all outstanding QA issues

Instruction Steps

Resubmit record to Incident Manager, step 3.5

Outputs

Updated Incident Record

3.10
Purpose

Incident Manager Closes Incident

Incident passed the Quality Assurance check
enabling the Incident

to close the record

Requirement Statement Coordinator
All Incident Records will be closed upon completion
Inputs
Procedure or Work
Instruction

Incident Record
Incident Manager changes the status of the record
to closed.

Outputs

Closed Incident Record

3.11

Tech Closes Incident Record

Purpose

If no Quality Assurance check was needed, the

technician closes the incident record

Requirement Statement All Incident Records will be closed upon completion
Inputs
Procedure or Work
Instruction
Outputs

3.12
Purpose

Incident Record
Technician changes the status of the record to
closed
Closed Incident Record

User Notified of Incident Closure

The user must be notified that their Incident has
been closed in

ITSM must
tool be notified when their Incident Record
Requirement Statement the
All users
has been
Inputs

Closed Incident Record

Procedure or Work

User is notified based upon their notification

Instruction

preference

Steps

If preference is email then automated email

generated from the ITSM tool is sufficient
If preference is telephone, the Support Center is

Outputs

notified
and will follow
up with the User via
User Notification
of closure

8.2 Incident Management Verification, Document and Closure Process

RACI Matrix

Activity

IM Process
Service
Service
Owner/Mana Desk
Provider
ger
Technician Group
Incident
Manager

Service
Provider
Group

User

Technician

3.1 Primary Tech

Verifies Resolution

3.2 Confirm with

User
Incident can be
3.3 Update
Knowledge
base and Incident
Record
D.3.4 Is Additional
Incident Manager
Review Required?

3.5 Technician
Proposes
Closing Incident
3.6 Incident
Manager
Verifies Optional QA
Questions
D.3.7 Passes QA
Check?
3.8 Reassign Record
to
Technician
3.9 Tech Resolves
QA
Issue
3.10 Incident
Coordinator Closes
Incident

3.11 Technician
Closes
Incident Record

R
R

8.3 Reports and Meetings

A critical component of success in meeting service level targets is for organization
to hold itself accountable for deviations from acceptable performance. This will be
accomplished by producing meaning reports that can be utilized to focus on areas
that need improvement. The reports must then be used in coordinated activities
aimed at improving the support.

8.3.1 Reports -Service Interruptions

A report showing all incidents related to service interruptions will be reviewed
weekly during the operational meeting. The purpose is to discover how serious the
incident was, what steps are being taken to prevent reoccurrence, and if root cause
needs to be pursued.

8.3.2 Metrics
Metrics reports should generally be produced monthly with quarterly summaries.
Metrics to be reported are:

Total numbers of Incidents (as a control measure)

Breakdown of incidents at each stage (e.g. logged, work in progress, closed
etc.)
Size of current incident backlog
Number and percentage of major incidents
Mean elapsed time to achieve incident resolution or circumvention, broken
down by impact code
Percentage of incidents handled within agreed response time as defined by
SLAs standards
Number of incidents reopened and as a percentage of the total
Number and percentage of incidents incorrectly assigned
Number and percentage of incidents incorrectly categorized
Percentage of Incidents closed by the Service Desk without reference to other
levels of support (often referred to as first point of contact)
Number and percentage the of incidents processed per Service Desk agent
Number and percentage of incidents resolved remotely, without the need for
a visit
Breakdown of incidents by time of day, to help pinpoint peaks and ensure
matching of resources.

8.3.3 Meetings
The Quality Assurance Manager will conduct sessions with each service provider
group to review performance reports. The goal of the sessions is to identify:

Processes that are working well and need to be reinforced.

Patterns related to incidents where support failed to meet targets

Reoccurring incidents where the underlying problem needs to be identified

and resolution activities are pursued
Identification of work around solutions that need to be developed until root
cause can be corrected