Site Specific Standard Global

Standard Operating Procedures

Working Incidents in Service Center
Standard Association: Incident Management Global Work Instructions
Incident Management ServiceCenter Workbook
Owner: Regina Sober

INTRODUCTION
This document outlines policies and procedures for Tier 2/3 teams in taking ownership of assigned Service
Center Incidents and working them up to resolution. Incidents and tickets are opened when a device or
service is not functioning as designed. Incident Management is focused on restoring service as quickly as
possible. Often this involves application of a temporary fix or workaround.
POLICY STATEMENTS
Service Center Incidents

Incidents dispatched to Tier 2/3 support teams will be placed into Work in Progress (WIP) status
upon receipt and acceptance, or reassigned to another team as needed.
Acknowledgement of the Incident will happen by the person working the incident. Initial message
should contain the incident number, what it is regarding and an estimated time of completion. This
email shall be copied and pasted into the incident. (Example: Thank you for contacting us
concerning Incident # 100-02-xxxxxxxx. We have received your request and I will be handing your
incident. I estimate this to be resolved by: xx/xx/20xx. If you have any questions/concerns, please
contact me.)

Tickets should not be left in Open Status longer than 1 business day without being assigned and
moved to Work In Progress status.

Documentation of all correspondence to the client and work done on the incident must be copied
into the incident so that if the agent working on the incident be out unexpectedly, a teammate may
assist in keeping the ticket moving forward.

Confirmation of incident closure must be done with the user via phone, IM or email stating (example:
your concern in incident XYZ has been completed, if we dont hear from you within 3 business
days, your incident will be closed If no response after set date, close ticket and note no response.

Tickets should be updated immediately as actions occur and detailed results.

Incidents will be updated weekly (on Fridays) if there are no actions taken throughout the week by
the Assignee stating no action, why there is no action; unless noted differently in the ticket (example:
Awaiting to deploy into production on 6/12).

Any change in the status of the ticket requires proper documentation in the ticket regarding why the
status change was made.

Incident needing reassignment will be updated to reflect the reason for reassignment, and will be
warmly transferred if Severity 1 or 2.

Incident will be suspended only as a result of a client (or clients vendor) caused delay in restoring
service (SLA stops). Proper documentation on why the ticket is suspended.

Incident will be on hold only as a result of the support team working the incident waiting on a
response from the customer (SLA does not stop).

Incidents for Move/Add/Change requests (IMACs) must be updated to severity 5.

Prior to closure, verify the appropriate case logging and severity are appropriate for the end
problem. Use the appropriate resolution code.

Duplicate incidents will be associated and closed appropriately to avoid double counting in metrics.

SERVICE CENTER STEP-BY-STEP PROCEDURES

These steps are required to successfully execute the policies.
Reassigning an Incident: To be performed when the Incident has not been resolved, and resolution actions
must be performed by another support group or individual.
1. Open the Incident record and review the information in the record to ensure that the assignment is
valid. If the assignment is not valid, then reassign by clearing and updating the Primary Asgn
Group or Assignee Name field.
2. Click on the Activities tab, then Action/Resolution. Select a Type from the dropdown and add an
update that states why the ticket is being reassigned in the Corrective Actions field. Save the
record.
Moving an Incident to Work in Progress (WIP) status: To be performed when assignment is valid and
Assignee has begun to work the Incident.
3. Click on the Incident Details tab. Determine the individual within your team who should own the
Incident and enter their NET-ID into the Assignee Name field (or select the name from the menu
using the ellipses).
4. Enter the time that problem investigation began in the First Customer Contact Time field.
5. Click on the Activities tab, then Action/Resolution. Select a Type from the dropdown and add an
update that states that work has begun on the issue in the Corrective Actions field.
6. Save the record. The status will move from Open to Work In Progress, which indicates that the
assignee has acknowledged and begun work on the issue. This stops the SLA clock for time to
respond.

Updating an Incident to document progress made and actions taken: To be performed regularly as
progress is made in Incident diagnosis and troubleshooting, leading toward resolution (restoration of
service or normal state). Making regular ticket updates ensures a record is maintained of actions taken;
this reduces confusion and ambiguity over actions previously taken during and following Incident
resolution.
1. Click on the Activities tab, then Action/Resolution. Select an appropriate Type from the dropdown
and add an update that reflects the current status.
2. Save the record.
Placing an Incident into Hold or Suspend Status: To be performed when there is a delay in restoring
service; use Hold when the delay is HP or HP vendor caused, and Suspend when delay is at client
request or due to clients vendor. Suspend status stops the SLA clock, but Hold does not. Suspended
Incidents will have the SLA clock in DW stopped until either the Incident is Unsuspended or when the
reactivation time is reached.
1. Right click on the incident from the Incidents Menu Bar, select either Suspend Incident or Hold
Incident. This will bring up a window.
2. Enter the Reactivate Time by clicking on the ellipses and selecting the appropriate date/time for
when the delay is expected to end.
3. Enter text explaining why the Incident is being placed into Hold/Suspend into the Justification field.
Save the record.
4. To manually take a ticket out of Hold or Suspend, right click on the incident, then either Unsuspend
Incident or Unhold Incident, then enter text into the Justification field and click OK. Save the
record.
Working Duplicate Incidents: A duplicate Incident occurs when more than one Incidents record is opened
for the same Incident occurrence. This should not be confused with an Incident Recurrence, which is
multiple occurrences of Incidents that are caused by the same problem. The steps below are to be followed
to Associate and close duplicate Incidents so that an outage is not counted twice in metrics.
1. Identify the master Incident and the duplicate Incident that we wish to Associate and close to the
master. Open the duplicate Incident.
2. Select right click on the incident, then Related, then Incidents, then Associate. Enter the Incident
record for the master (use the full number of 100-02-xxxxxx) and click OK.
1. Click on the Resolve icon in the menu bar.
2. Select Fix Type using the radio of Temporary.
3. Review the Down Time Start and Down Time End fields and make corrections if necessary.
4. Select the Closure Code of Duplicate by clicking on the ellipses and double clicking on the
selection.
5. Correct the Severity to 5 to ensure that the record will not be double counted in metrics.
6. Select the appropriate Resolution Owner (EDS, Client or 3rd Party) from the dropdown selection.

7. In the Solution field, enter text describing that this is a duplicate of another ticket and provide that
ticket number. Click on Save. The record is in Resolved status.
8. Click on the Close icon in the menu tray. Click Save or OK.
Closing Incidents: To be completed once the customer confirms the issues raised in their incident have
been resolved.
9. Open the Incident that needs to be closed.
10. Click on the Resolve icon in the menu bar.
11. Select Fix Type using the radio of Permanent.
12. Select the Closure Code by clicking on the ellipses and double clicking on the selection that best
fits the reason appropriate for the fix done to resolve the Incident.
13. Correct the Severity as appropriate to ensure that the record reflects the actual business impact of
the incidents - see Severity/Priority definitions. Ensure Incidents regarding Move/Add/Change
activities have a Severity 5.
14. Select the appropriate Resolution Owner (EDS, Client or 3rd Party) from the dropdown selection.
15. Select the appropriate Result of Change (Yes or No). Select yes if this Incident was part of a
change request.
16. In the Solution field, enter text describing that this is a duplicate of another ticket and provide that
ticket number. Click on Save. The record is in Resolved status.
17. Click on the Close icon in the menu tray. Click Save or OK.

MORE TO KNOW
Severity 1 or 2 issues should rarely if ever be suspended, since if the client does not want service restored
right away it is unlikely to be causing Critical or Major client impact. Similarly, tickets should not be
suspended pending client confirmation of service restoration because if the Incident is causing Major or
Critical client impact, then the customer (or customer representative or CSR) should be available 7x24 to
confirm that service is restored.

Severity Level Definitions

Severity 1
Critical impact - An Incident causing a complete interruption or extreme degradation of service delivery to the
affected client, environment or business operation. Those affected cannot utilize affected services until service
delivery is restored.
Severity 2
Major impact - An Incident causing a significant interruption or degradation of service delivery to the affected client,
environment or business operation, though a contingency plan allows those affected to achieve partial functionality
during the event.
Severity 3
Moderate impact - An Incident causing a moderate interruption or degradation of service delivery to the affected
client, environment or business operation. While immediate impact is moderate, the risk for increased impact may
be apparent. There may be an automated or manual contingency plan that allows those affected to achieve a level
approaching normal service delivery during the event.

Severity 4
Minor impact - An Incident causing a minimal interruption or degradation of service delivery to the affected client,
environment or business operation (includes single user issues). An automated or manual contingency plan may be
available.
Severity 5
No current impact - An Incident that does not affect normal service delivery for a client, environment or business
operation. Includes issues with the potential to cause impact if not proactively addressed, and those that began as a
higher severity due to Potential Impact, but were resolved prior to causing Actual Impact.

Service Restoration Targets:

Severity

Impact

Sev 1

Critical

Restoration
Target
4 hours to complete

Sev 2

Major

8 hours to complete

Moderate
Minor
No current

2 days to complete
5 days to complete
5 days to complete
22 Days to
complete

Sev 3
Sev 4
Sev 5
Sev 5 WFM

No current

SLA to Use
100-2667
100-1217 (KM Use 1002127)
100-30
100-2630
100-2630
100-2768

Note that these are HP defined targets. The contracted SLA for the affected environment may outline
different targets that take precedence over those defined here.

Definitions
Actual
Impact

The true effect an Incident has on an affected client, environment or business operation, based
on an assessment of the level of service degradation actually experienced during the Incident.

Potential
Impact

The effect an Incident may have if not addressed before exceeding a new threshold of service
degradation. Used for establishing a severity level based on Urgency and Priority more than on
current Actual Impact, to allocate the resources required to act on the Incident and to minimize
or avoid any Actual Impact.

Severity
Level

A measurement of the adverse effect an Incident has on a client, environment or business

operation, based on its impact and urgency.

More to know
If you receive a ticket that is not for your inbox, but another BPS teams inbox, please reassign it to the inbox, not to
the CEDS_HD inbox to help keep the ticket moving.
If you do not know what inbox to assign it to, please contact Regina Sober or your leader for assistance.
Application/Service
AIC
BPS Web
CX on Demand - ACD
CX on Demand - IVR
CX on Demand - QM
CX on Demand - WFM

DW inbox
Z_IC_CTI
CEDS_KNOWLEDGE_MGT_SUP
CEDS_CEAAS_ACD
CEDS_CEAAS_IVR
CEDS_CEAAS_WFO_QM
CEDS_CEAAS_WFO_WFM

CX on Demand WFMROC Team

DEP
ePresentment
IVR - Application
Development
IVR - Production Support
QM
WFM - Level 2
WFM - Level 3

CEDS_CEAAS_HC_ROC
CEDS_DEP_SUPP
CEDS_IBILLING
CEDS_CSS_IVR
CEDS_ICM/IVR
CEDS_NICE_SUPPORT
CEDS_WFM_RSO
CEDS_WFM_APP_SUP

Revision History
Version

Date

Reviewed by

Approved by

Summary of Change(s)

1.0

10/6/2014

Regina Sober

Regina Sober

Initial draft authored by David Mann

1.2

4/7/2015

Regina Sober

Regina Sober

Updated service restoration section.

1.3

12/2/2015

Regina Sober

Regina Sober

Updated SLA information and added assignment inboxes

section.

1.4

2/11/16

Regina Sober

Regina Sober

Updated assignment group information.