BPOST Training INCM Process Guide

Training INCM Process Guide
BPOST account
Dena Asenova, INCM APL, SM & OE org
© 2020 DXC Technology Company. All rights reserved.

Content:
I. Service Level Requirements
1. Incident Resolution
2. Incident Response & Incidents caused by change
II. Reprioritization
III. HPIM Engagement for P1/P2 Incidents
1. Overview
2. Contacts
3. In addition
IV. Case Exchange
V. Pending Customer Status
1. Correct Usage
2. ! Do not use Pending Customer
3. 3 strike rule - Don't unnecessarily spam the user
V. Proper closure comments
© 2020 DXC Technology Company. All rights reserved. October 19, 2023 2
Service Level Requirements for Incident Resolution
Incident resolution Service Measure Performance target

Priority Level 1 Time to Resolve <8 hours (<4 hours for
technical workaround)
Priority Level 2 Time to Resolve <12 Business hours
Priority Level 3 Time to Resolve <5 Business days
Priority Level 4 Time to Resolve <5 Business days
For each of these Service levels we need to reach a target of 98%.
Note there is a high Management visibility and focus on SLA area and our Targets are:
- to improve the SLA process compliance,
- to ensure correct and transparent SLA Reporting for Resolution Time,
- to avoid Customer Escalations.
Please reply to every SLA Warning email that you may receive from ILC daily.
Additional Service Level Requirements
Incident response SLRs
Incident response Service Measure Performance target
Priority Level 1 Time to Respond Monday – Friday
07:00 – 18:00
15 mins
Monday – Friday
18:00 – 07:00
Weekend and Bpost Holidays
30 mins
Priority Level 2 Time to Respond N/A
Incident type Service Measure Performance target

Incidents due to change Number of P1 and P2 <=2 Incidents per
incidents due to change measurement period
Reprioritization - only done by BPOST Managed DCC
Control room in SNOW
The Critical Incident Management (ARL/ Manager on duty / HPIM Team) only in alignment with bpost Incident manager/Duty
manager are empowered to approve the decrease / increase of the priority of a P1 incident.
Automated alerts within DXC supported IT environment are subject to reprioritization as seen feasible by the responsible IT
support engineers.
IMPORTANT: Reprioritizing an incident has an impact on the overall Service Level Management area, as “Time to Own” and
“Time to Resolve” metrics in DXCSM have been already calculated based on the initially assigned priority.
As an outcome, changing priority at a later stage may result in reducing SLO targets for support teams. Therefore, it has been
agreed that any required adjustments will be first discussed over the phone between DXC technical support teams / Critical
Incident Management (Manager on duty / HPIM Team) and bpost representatives –bpost Incident manager/Duty manager – and
upon agreement reached the Priority can be adjusted as follows:
When a downgrade is needed priority will be amended in ServiceNow and information exchanged automatically to DXCSM.
In case of priority upgrade, the originating incident record will be closed, and new incident record will be created with higher
priority. The initiating tool for both transactions is ServiceNow.
Note: for tickets originating from DXC (e.g. in DXC SM) it is the DXC SM ticket that need to be downgraded or upgraded
following the same logic as outlined for bpost originating tickets.
HPIM Engagement for P1/P2 Incidents Overview
 Overview
Starting immediately the Global HPIM team will be available 24x7x365 in designated Microsoft Team channel available
to all DXC capabilities, who want to report a high priority incident.
As of June 29th, 6:00 AM CDT the Global Command Center no longer monitors the High Priority Incident Management
MyRoom.
The DXC Resolve Engagement Portal will continue to remain as Primary Engagement method for HPIM. We encourage
all iAciton/iSolve/iServe / Account/etc capability groups to use it as one stop shop for all HPIM engagements.
 HPIM presentation_Back to Basics_v6
Microsoft
 Handling P1 and P2 Incidents
PowerPoint Presentation
Every actual P1 and P2 incident no matter if it is End user raised or created from Monitoring tools should trigger the
HPIM (High Priority Incident Mgmt) process when there is customer impact.
Every team can trigger the HPIM team when it becomes aware of an incident with a big impact or potentially big
impact on the customer. However, this task should be usually performed by the PEM (Production Environment
Manager).
HPIM Engagement for P1/P2 Incidents - Contacts
 Contact HPIM Command Center Escalation Room
1. You can access into Microsoft Teams:

 Web link Click here. (You need to authenticate using global pass)
 Desktop/Mobile app:
o Download Microsoft Team app fist (Available in O365, App or Play Store)
o Enter using code: zhexj6a
o Or search for “Global Command Center” and join the Team directly without being added.
2. Report high priority incidents
 Click on “! Outage Escalation Room” to communicate outages

 Do NOT post in the General Channel.
 Use the following format when reporting an incident: Incident Start Time; Priority Start Time; Impacted Customer
; Impacted KPE; * Impacted CI(s) ; Incident Ticket ID ; * Change Ticked ID ; Incident Description; Service Impact
Description; * Actions taken/Engaged/Required Resources (*: if applicable)
HPIM Engagement for P1/P2 Incidents – In addition
 What to expect from HPIM Command Center?
 DXC HPIM representative will contact you immediately
 DXC HPIM will open technical “meet me line” and engage Run capability groups
 DXC HPIM will Issue Initial targeted notification to a pre-defined response group (technical scenario)
 DXC HPIM will validate the reported critical incident and agrees with the PEM on the RtOP content
DXC HPIM will continue running the process to drive rapid recovery of the impacted key production environment.
 Useful Resources
 Teams Transition Frequently Asked Questions

 DXC MS Team Users (workplace)
 Global Incident Command Center / HPIM Reference card
 High Priority Incident Management Training
 Process Viewer
 RtOP Procedure
Case Exchange: HPSM Incident handling
- The SD queue should only be used for
- incidents which can be solved by service desk (if required with instructions for the SD agent)
- incidents whereby more information Is required from the user or the user should be contacted
- incidents whereby the incident description should be translated when completely unclear.
- SD queue: E-CUSTINCFLS-BPST-GSD-SX
- The misroute queue should only be used for

- Incidents whereby we need support or more information from DCC
- Incidents which have been wrongly assigned and need another non-DXC support group involvement.
- Misroute queue: E-CUSTINCFLS-BPST-MISROUTE-SX
- IMPORTANT:
When an incident needs to go to another DXC assignment group and the team is known, internal rerouting should take place.
- These incidents should not go back to SD or Misroute queue.
- When we are in doubt if another DXC team can help or not, check with your DXC colleagues first before dispatching the ticket to
the misroute queue.
- Status ‘pending vendor’ should never be used. This is a not authorized status for this client.
- Tickets should always be accepted first (click accept) even when they are not for us and need to be re-assigned to
the misroute queue.
- Always put an update in the incident when you re-assign to another team.
 The DXC-Bpost Assignment groups you can find in the Contact Matrix: Microsoft Excel
Worksheet
Case Exchange: High level overview ticket re-assignment
Accept + Update
Ticket received and needs Reassign it internally to the
to be reassigned correct team. DO NOT use
to known other DXC team the misroute queue.
Always put
Ticket received and needs Accept + Update an update in
to be reassigned Reassign the ticket to the
the incident,
to unknown team or non- misroute queue
NOT simply
DXC team
re-assign
Ticket received and we are in Accept + Update Check with your DXC
doubt if it needs to go to colleagues and reassign
another DXC team or not. afterwards internally or to
the misroute queue
Correct Usage of the Status Pending Customer
3 Strike Rule Process and correct Usage of Pending Customer status to be ensured
when you require an action or additional information from Customer.
 Perform 3 attempts to contact the customer in 3 consecutive days for P3 and P4 incidents.
If no response, set the incident to Resolved Status on the next day.
! 3 Strike Rule does not apply on incidents for which DXC has provided a resolution. (No matter if provided via email, in the incident notes…)
After providing the resolution, these incidents should be put in Resolved status immediately because if required Bpost users still have 5 days to
react or to reopen their tickets in SNOW.
Additional Usage of Pending Customer status allowed:

 Each incident which is sent to E-CUSTINCFLS-BPST-GSD-SX or E-CUSTINCFLS-BPST-MISROUTE-SX needs to be put on Pending
Customer status
o When you expect an action or additional information from a Bpost 3rd Party Vendor
o When you need Language Support for translation in English
o If you are pending Customer confirmation for Onsite Appointment (for Onsite Support/Visit)
 If there is an Ongoing Change request that will resolve the incident after it is implemented
! Do not use Pending Customer
! Do not use Pending Customer when you expect an action or information from another DXC Support Team.
You should use Work in Progress Status and reassign the incident directly to the respective DXC Support Team/DXC
3rd Party Vendor and/or contact the DXC engineer directly for an update vie skype/email/call.
Note: It doesn’t matter for the Customer if the case was at DXC 3rd Party Vendor hands or at DXC as, the
responsibility in both cases falls under DXC.
Pending Customer is the only status that stops the SLO Clock. SLO clock is working when Status is Work in
Progress.
Comply with the General Rules for Status Updates:

1) P1 to be updated once in every 1 Hour; P2 – twice in a Business day; P3 – once daily
2) Include meaningful information about investigation performed, results, or expected actions.
3) High quality daily Status Updates are critical to ensure timely resolution and green SLAs.
3 strike rule - Don't unnecessarily spam the user
The 3 Strike Rule should be followed after all the information in the ticket has been read, and it has been also checked
for attachments.
Please take into consideration the previous team’s comments.
The user shouldn’t be spammed with the same questions as this will lead to escalations.
Important: All attempts (strikes) to contact the end-user must be documented in the ticket to ensure incident record
completeness and accuracy.
* If the end-user’ out of office mail response indicates that she/he is on vacation / leave / sickness: Restart with 2nd/3rd
contact on their return to work. A due date could be added in front of the title as ex. “OOO 30.11”, for overall awareness.
Solution field and proper closure comments
All user raised tickets need to be closed with appropriate “Close Notes”.
 Provide some meaningful information when resolving the tickets.
Do not close client raised incidents with statements like “Resolved”, “Solved”, “Issue fixed”, “Call solved completely”, etc.
 Write with your own words in brief what has been done to resolve the issue.
It will be clearer for the user and for everyone who investigates the incident, especially for the Problem Manager if a
Problem ticket should be opened.
Thank you!

BPOST Training INCM Process Guide

Uploaded by

Copyright:

Available Formats

You might also like

BPOST Training INCM Process Guide

Uploaded by

Document Information

Original Description:

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

BPOST Training INCM Process Guide

Uploaded by

Copyright:

Available Formats

Training INCM Process Guide

© 2020 DXC Technology Company. All rights reserved.

Incident resolution Service Measure Performance target

For each of these Service levels we need to reach a target of 98%.

Incident type Service Measure Performance target

1. You can access into Microsoft Teams:

2. Report high priority incidents

 Click on “! Outage Escalation Room” to communicate outages

 Teams Transition Frequently Asked Questions

- The misroute queue should only be used for

Additional Usage of Pending Customer status allowed:

Comply with the General Rules for Status Updates:

You might also like