Incident Ownership and Communications
Policy
Version / Version 4.3TRIM file number
Short description / DIT Incident Ownership and Communications Policy
Relevant to / Incident and Request Management
Approved by / Executive Director,
Division of Information Technology
Responsible officer / Executive Officer of Information Technology
Responsible office / Office of Executive Director of Information Technology
Date introduced / 1 March 2010
Date(s) modified / 4 November 2011
11 April 2012
1. September 2014
2. September 2016
Next scheduled review date / 30 September 2019
Related legislation
Key words
Contents
Introduction 1
Scope 1
Definition of an Incident 1
Timing 1
Responsibilities 1
Method 2
Incident Handling Procedure 2
Incident Ownership 2
Communication 2
Process Flow 3
Incident Handling Workflow Diagram 4
Workflow Steps Definitions 5
Response 5
Incident process 5
Response levels/times 7
With Customer 8
With 3rd Party 9
Entering Time Spent 9
Re-assigning Incidents 10
Resolving Incidents 10
Re-Opening Incidents 10
Note in Incidents 11
Incident Prioritisation 12
Overview 12
Prioritising by Incident Type 12
Appendix 13
Escalation process of suspected outage or disruption 13
Teaching space & High Priority VC calls procedure 14
Service Desk Procedure 14
Personal Computing Procedure 15
Document Revision 16
1. Introduction
This document has been developed to guide staff of the Division of Information Technology (DIT) and partner Divisions using the DIT ITSM tool (LANDesk), with the ownership, communications and handling of an incident raised by clients. This is to ensure there is an effective response, escalation, investigation, resolution and communication carried out during the incident lifecycle.
2. Scope
This document defines the communication process and steps required to ensure an incident is acted on as quickly as possible to restore normal operation and minimise the adverse impact on business operations.
Definition of an Incident
An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service. We also use incident handling to respond to requests such as access to a system or service and to provide task assignments to staff.
Where an incident has a high impact and urgency on clients being affected, IT support staff will then need to refer to the Significant/Critical Incident procedure to execute the required response.
3. Timing
Effective from the date of this Policy creation.
4. Responsibilities
All staff within DIT and support partners are to adhere to the Incident Handling Procedure. Team Leaders and Managers of relevant sections are to ensure staff in their teams are conversant with this procedure.
Clients will be able to see all information regarding their incident through Online Self Service, therefore all support staff have the responsibility of ensuring their language is professional.
Incidents flow between support teams in Landesk in the following manner: 1st Tier: Service Desk
2nd Tier: Infrastructure and Client Services Applications and Integration Technology Projects
Shared Business Services Division of Student Learning (DSL) Finance
Research Office
Division of Student Administration (DSA) Web Strategy Office (WSO)
Vendor
Information and feedback can flow between any of the teams using the processes defined within those teams as well as between any of the teams and a vendor.
5. Method
Incident Handling Procedure
This incident handling procedure outlines how an incident should be handled by DIT and support staff from client escalation to resolution covering:
• Ownership of an Incident
• Communication to and from the client
• Incident process flow through Landesk
Incident Ownership
The owner of an Incident is determined by whichever DIT or support staff member it is assigned to in Landesk at that time.
The Incident owner is responsible for any communication with the client.
The staff member becomes the owner of an Incident at the time the Incident is assigned to them. Ownership remains with the assigned analyst until such a time as the incident/request is resolved or re-assigned to another analyst.
Communication
The incident owner is responsible for communicating with the client. The first preference for communication is via the phone. If the client does not answer, a voicemail message must be left with an email sent from the ‘With Customer’ template in LANDesk to follow up.
The incident/request must not be closed until the client has confirmed their satisfaction with the resolution. If unable to contact via phone, leave a voicemail message and follow up with an email.
The client may be contacted by more than one DIT or support staff member during the lifecycle of an incident/request. All communication must be noted in the incident/request to ensure all staff are aware of previous communications and enable professional client contacts.
Process Flow
All incidents handled by DIT and support staff follow these steps:
Identification: How an incident is identified to DIT
E.G. By phone, web form, face to face or by another means. Logging: All incidents are to be placed in LANDesk with all relevant information. Categorised: The most relevant category is initially selected.
Prioritised: This is done automatically by LANDesk according to the category selected. This is referred to as the response level.
Diagnosis: Discover the full symptom, what went wrong and how to correct it.
Escalation: To 1st or 2nd tier support levels.
Response: The response action is required after an escalation or reassignment. This is to ensure the client is communicated with in regard to what is happening with their incident/request
Investigation: Analysis of the incident and cause.
Resolution: Apply a fix to the incident and test the fix by confirming with the client their issue is resolved.
Record the resolution details in the logged incident and close the incident with the most relevant category.
Ensure the time taken to complete any work related to the incident is recorded.
Follow up: Gain feedback from the client on their experience with DIT and other support staff.
Process on re-opens, ie within what timeframe. KB’s and FAQ’s updated or created.
Incident Handling Workflow Diagram
Support AREA
Service Desk
COMMS
Ph, web form, Self Service email or face to face
PROCESS FLOW
Client contacts DIT by web form or self service
PROCESS STEPS
1. Client contacts DIT by phone, web form or self-service.
2. If web form or self-service, client may be called to investigate issue.
LANDESK ACTION
3. Create new job or add relevant note in LANDesk for every client enquiry.
Service Desk
All Teams Start Here (After the Incident is escalated)
Phone
Phone, Email
Client contacts DIT by phone
Call client to investigate
Can client
be No
contacted?
1. Analyse what has occurred and determine cause.
- Response required. If client can’t be contacted by ph to obtain more details, leave vm + send email via Landesk.
2. If waiting for information from client change status to “With Customer” & put details into the window + tick box to send email.
Yes
Is issue fixed?
Yes
No
Enter Time taken
- Refer to process on Entering Time Taken below.
- Click on “Time and Cost” and enter Date and Time.
RESOLVED
- Refer to process on Resolve Incidents below.
- Click on “Resolve” and enter details on steps taken to resolve.
Phone, Email
Assigned to personal queue‘s by an individual or allocated person
Contact 3rd Party
Service Desk escalate
Escalate Incident
- Contact a 3rd Party depending on the procedure for the issue being investigated.
- LANDesk will escalate to correct group by category selected.
3. Change status to “With 3rd Party” & put details into the window.
4. Click on “Escalate”.
Team Leaders assign to personal queues
Reassign
- Re-assign to another tier 2 group if required.
- Click on “Re-Assign” and select the group name only unless specified
Workflow Steps Definitions
Response
The response process is to improve the management of client expectations through the lifecycle of an incident by providing a timely response through improved communication for a better client experience.
The response time is the amount of time set that an analyst has to respond to a client when a job is escalated or reassigned in LANDesk.
This means that analysts will need to make contact with the client by phone within the allocated response time. The Response Time is the maximum time set for contact to be made with the client when the job is received. The response can be by either providing the client with a fix for the issue, or advice on when the issue may be fixed.
The Response Time will be indicated within the Incident in the Response field and can be provided to the client by tier 1 to manage client expectations.
The breached response box will be marked by the system if the incident has not been responded to within the current Response Level setting. Incidents will change to a blue colour if the response level is breached.
Incident process
This process applies to all analysts (individuals, teams and groups) that use LANDesk to manage incidents and requests assigned to them at any part of the lifecycle of an incident or request.
- An incident can be logged by Service Desk staff or any other analysts, escalated by Student Central, submitted via Online Self Service, or submitted by Web form (email)
- During the initial processing a category is selected and the incident saved
- The Escalate to group, the Incident type, the Response level and the Resolution level
are pre-defined and set according to the service category.
- Tier 1 (Service Desk) – can either Resolve the Incident or Escalate the Incident
- The escalation function is only used at this point in the Incident, when tier 1 is unable to resolve it at first contact. The escalate action will send the incident to the group assigned to the category that is selected.
- At times tier 1 (Service Desk) may need to gather more information or attempt some troubleshooting before escalating the incident to the Escalate to group defined by the service category. When the Escalate to group is not the Service Desk queue group, then tier 1 will Escalate and then Reassign to the Service Desk group queue.
• After Escalate is selected, actions available are Respond to the client, Resolve the incident or Reassign the incident
• With 3rd party and With Customer are available to be selected after escalation but only after the incident has been responded to. These actions are used when waiting on more information from the client, or waiting on a vendor or another party outside the assigned team or analyst.
• A staff member from the Escalate to group contacts the client within the response time. This communication is to provide a fix, commence troubleshooting, gather more information, or advise that the issue is being investigated. If not able to resolve, negotiation of a time to resolve should occur and the client made aware of when to expect the next communication.
• After contacting the client, staff receiving an escalated incident click on the Respond action, or if the job can be resolved when the client is first contacted, the incident is just resolved using current processes and the response process does not have to be used.
• After clicking Respond, a pop up window will appear where an analyst will enter what communication they had with the client. This includes what information was provided to the client when they called (also includes leaving the details of a voicemail)
• Clients will be able to see respond notes in Self Service
• The Response Time clock will then be stopped as the incident has been responded to.
• If the escalate to group needs to escalate to another group, this is done by re-assigning the incident.
• After Reassign is selected, actions available are Respond to the client, Resolve the Incident, or Reassign the Incident
• The response clock starts again
• With 3rd party and With Customer are available to be selected after reassignment but only after the incident has been responded to.
These actions are used when waiting on more information from the client, or waiting on a vendor or another party outside the assigned team or analyst.
• A staff member from the reassigned group contacts the client within the response time. This communication is to provide a fix, commence troubleshooting, gather more information, or advise that the issue is being investigated. If not able to resolve, negotiation of a time to resolve should occur and the client made aware of when to expect the next communication.
• After contacting the client, staff receiving a reassigned incident click on the Respond action, or if the job can be resolved when the client is first contacted, the incident is just resolved using current processes and the response process does not have to be used.
• After clicking Respond, a pop up window will appear where an analyst will enter what communication they had with the client. This includes what information was provided to the client when they called (also includes leaving the details of a voicemail)
• Clients will be able to see respond notes in Self Service
• The Response Time clock will then be stopped as the incident has been responded to.
Note
The response clock starts at the escalate action or each reassign action and is stopped by the respond action.
The reassign action should not be used multiple times by analysts to try to reset the response clock. Generally there should be a response between each reassignment to an analyst.
When an incident has breached response time it will change to a blue colour and an email may be sent to the team leader of that group alerting them an incident assigned to their group has breached response time.
Response levels/times
Response levels are assigned to service categories listed in LANDesk
Response times are for individual incidents and do not apply with issues relating to significant or critical incidents for these services in which a higher level of response may be required.