Incident Ownership and
Communications Policy
Version
Version 4.2
TRIM 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
29 September 2014
Next scheduled review
date
Related legislation
Key words
4 November 2012
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 ............................................................................ 3
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 ................................................................................................. 11
Note in Incidents ......................................................................................................... 11
Incident Prioritisation ......................................................................................................... 12
Overview .................................................................................................................... 12
Prioritising by Incident Type........................................................................................ 12
Teaching space & High Priority VC calls procedure ......................................................... 13
Service Desk Procedure ............................................................................................. 13
Personal Computing Procedure.................................................................................. 15
Document Revision............................................................................................................ 16
1. Introduction
This document has been developed to guide staff of the Division of Information
Technology (DIT) for the ownership, communications and handling of an incident raised by
clients to DIT. 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. In DIT 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, DIT 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 the division 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 DIT staff have the responsibility of ensuring their language is
professional.
Incidents flow between DIT support teams in Landesk in the following manner:
1st Tier: Service Desk
2nd Tier: Infrastructure and Client Services
Vendor
3rd
Tier: Applications and Integration
Enterprise architecture
Technology Projects
Shared Business Services
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.
1
5. Method
Incident Handling Procedure
This incident handling procedure outlines how an incident should be handled by DIT 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 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 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.
2
Process Flow
All incidents handled by DIT 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 , 2nd & 3rd 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.
Process on re-opens, ie within what timeframe.
KB’s and FAQ’s updated or created.
Incident Handling Workflow Diagram
3
DIT AREA
Service
Desk
PROCESS FLOW
COMMS
Ph, web form,
email or face to
face
PROCESS STEPS
Incident escalated to DIT
- Client contacts DIT by phone,
web form.
- If web form, client may be called
to investigate issue.
Client contacts DIT
by web form
Service
Desk
All Teams
Start Here
(After the
Incident is
escalated)
Phone
LANDESK ACTION
Client contacts DIT
by phone
Phone,
Email
Call client to
investigate
- Analyse what has occurred and
determine cause.
Can client
be
contacted?
- Response required. If client
can’t be contacted by ph to
obtain more details, leave vm
+ send email via Landesk.
No
Leave client a
voicemail msg + send
email from LANDesk
- Create new job or add
relevant note in LANDesk
for every client enquiry.
- 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
RESOLVED
Escalate Incident
Phone,
email
ICS
Contact 3rd Party
vendor
- Refer to process on Entering
Time Taken below.
- Click on “Time and Cost”
and enter Date and Time.
- Refer to process on Resolve
Incidents below.
- Click on “Resolve” and
enter details on steps
taken to resolve.
- Contact a 3rd Party depending on
the procedure for the issue being
investigated.
- Change status to “With 3rd
Party” & put details into the
window.
Assigned to personal
queue ‘s by an individual
or allocated person
Service Desk
escalate
- LANDesk will escalate to
correct group by category
selected.
- Click on “Escalate”.
Team Leaders will
assign to personal
queues
ICS escalate
- Re-assign to Apps, Integration
or other tier 3 group.
- 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 will 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.
Some older incidents may display different colours that indicated when the resolution time
had passed; this is no longer being used and only the blue for breached response will be
significant.
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.
Customer logs an incident with the Service Desk






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.
Incident is Escalated








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 reassigning the incident.
Incident is Re-assigned





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 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.
6



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 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.
Levels
Response
times
Defining a Service category to a response
Level 0
Level 1
Level 2
immediate
15 minutes
1 hour
(60 mins)
4 hours
(240 mins)
Critical
Teaching interrupted (is an immediate response)
Client is unable to continue working (network
point issue, pc not working at all, VC connection)
Client can continue working however services
are degraded (email not working, phone not
working, student internet credit)
Requests (access to a system, new s/w
installation) **will actually show as 10hrs in
LANDesk
Requests (Billing questions, enhancements to
systems, Comms Directory updates)
Level 3
Level 4
1 day
(600 mins)
Level 5,
2 days
(1200 mins)
Current
Resolution
levels
immediate
4 hours
2 days
4 days
2 weeks
4 weeks
Note
Time calculated in LANDesk is Monday to Friday between 8am and 6pm
1 day is calculated as 10 hours (600 mins)
2 days is calculated as 20 hours (1200 mins)
7
With Customer
When a client needs to be contacted to obtain further information to assist in the diagnosis
and investigation of an incident, this must be done by calling the client.
If the client does not answer the phone call to them, the following process must be
adhered to:
- Leave a voicemail message with the details of the information required.
- The Status of the incident in Landesk must then be changed to “With Customer” and
the template updated with the details of what information is required from the client.
This must then be sent as an email to the client by ensuring the tick box has been
checked next to “Notify Customer”.
Example: An email will be sent to the client, the highlighted section must be altered
After an incident has been ‘With customer’ for more than 5 days, the assigned analyst will
receive an automatic daily email alerting them to action this incident.
You are required to make contact with the client and advise them either by email or
phone/voicemail of the following;
“You have previously been notified by DIT that we needed more information from you.
This email advised that if we did not hear from you within 5 days working days, your
incident will be closed automatically. As we have not received further contact within the
5 days your incident will now be closed.
Please contact the DIT Service Desk if you require assistance with this incident.”
The incident is then to be closed with a note in the “Summary” field advising:
No further contact received from client
8
With 3rd Party
This status is used when the issue needs to be referred to a person or group who is not
within the currently assigned group and is not the client. This may be another DIT group, a
vendor or another person within the University. The Incident is changed to this status from
the time the 3rd Party is contacted, until they have either resolved the issue, or provided
sufficient information for the Incident to be resolved.
When the status of the Incident is changed to “With 3rd Party”, the following information
should be entered into the Details:
- Who the 3rd party is and their contact details if it is a vendor.
- What the 3rd party is going to do.
- When the 3rd party is expected to resolve the issue.
NB: The Service Desk and the Personal Computing teams follow specific requirements for
entering details into the “Model Number” and “Serial Number” fields for some incidents.
Entering Time Spent
Teams who do not use Replicon to record time must enter the time they spent working on
the incident using the Time and Cost in the Actions Section and/or the Time in the
Resolution Window of the incident. Check with your Team Leader if this required by your
team.
Time should be added to the incident on the SAME day that the analyst performs the work.
Adding time spent retrospectively can distort reporting on time spent on services and
should be avoided.
Analysts who are working on an incident that may take a long time to resolve should add
the time they spend on the job each day in the Add time cost action window. Staff should
not wait until they have completed the incident and add more than 7 hours to the time field
in the resolution window. This is so a true snapshot over a day/week/month period can be
obtained when measuring time spent by Analysts or time spent on Services. (Therefore
any single time entered over 420 mins cannot be correct, unless an analyst worked more
than 7 hours in one day on one incident)
Staff should estimate as closely as possible the amount of time spent. Too little or too
much time will corrupt the results equally.
There is no limit as to how many times you can use the Add time cost action window. It is
not necessary to add up your time on paper and then add it as a total figure. Time can also
be entered after an incident has been resolved, the incident does not need to be reopened. It should however be added on the day it was spent.
The correct format to enter time is in minutes – just the number of minutes only (no text).
The wrong format may mean that time is not counted.
Example; 2 hours work spent on an incident, the correct format is 120
Do not use - 2hours, 120mins, 120.5, XX, 120:00, 2:00, or any other characters such as `
or n/a
Analysts can fix time that was incorrectly added in the Add time cost action window, the
date the time was added will not change. Time added in the time field in the Resolution
9
window cannot be changed. Adding a minus figure as a time spent will not negate time
already added to an incident.
The comments field is only for comments relating to time spent. This information will
generally only be looked at by Team Leaders. If it is important for other Analysts who may
work on this incident to see these comments, use the ‘add a note’ action.
Re-assigning Incidents
An incident should in most cases, only be re-assigned to a LANDesk group and not to an
individual staff member (analyst) within that group. Exceptions to this can be, when
directed by a KB, or by senior staff to assign to a specific analyst. This is to ensure the
incident is handled in the most appropriate time frame by the most appropriate person
decided on by the team receiving the incident.
Incidents are handled in different ways once assigned to a group and in some DIT teams;
a particular person is responsible for assigning the incidents to staff within that team. This
process is done under the direction of the Team Leader for the relevant LANDesk groups.
When an incident is re-assigned, notes about why this incident is being re-assigned and
any further information that will help the receiving party, must be placed in the Title or
Details. Do not remove the existing information as this relates to the job details and is
emailed to the analyst that the job is re-assigned to.
The assigned analyst should check all existing notes in the incident as well.
Example:
Resolving Incidents
When an incident is resolved an attempt must be made to contact the client to confirm the
issue is no longer occurring for the client. Exceptions to this can be when a request for
access has been made or a Service Disruption is underway during that time, in which case
the client can be directed to the Service Disruption website.
The Summary text box in the resolution window is the only text that will be sent to the
client when the incident is closed. The Details of the Resolution will be available to the
client using Online Self Service.
10
Re-Opening Incidents
An Incident can be re-opened after it has deemed to be resolved, when a client has
contacted DIT advising the same issue was not resolved to their satisfaction. If a different
issue is being reported by the client, a new Incident must be opened.
Notes can be added to an Incident without having to reopen the Incident.
Note in Incidents
The Notes in a LANDesk job are used for entering information on where a particular job is
up to, i.e. if a job is going to take longer than expected or if further information is obtained
that will assist with the diagnosis and investigation of the incident. If an incident is to be reassigned, information can be entered as a note, or entered into the re-assignment window,
see next section on re-assigning incidents.
When an incident is set to ‘With Customer’, and the client contacts the Service Desk, the
status will be changed by clicking on ‘Back from Customer’ and notes added in that
window as well. The Service Desk will email the analyst to advise of the change in status.
When an incident is assigned to an analyst an automatic email is sent to that analyst when
any note is added.
The Note window contains a notes category field. This is now a mandatory field.
This is to ensure we get a very clear indication in our reports of why clients call back about
an existing incident or request.
Definitions of note categories and when to use each category
Analyst Update - Select this category when you are adding information that did not
originate from the Client.
Client Update - Select this category when you are adding information that the client needs
to add to the existing incident.
When a client calls to give more information that was missing to be able to complete their
incident/request
Customer Enquiry - Select this category when a client is enquiring to the status of an
existing incident.
When a client calls to find out where their job is up to or following up because they have
not received any communication
Customer Enquiry = Follow up contact required to client.
When the incident is assigned to a group but not an analyst the Service Desk will email the
Team Leader of the group to advise a client follow up is required.
When the incident is assigned to an analyst the Service Desk will email the assigned
analyst and the Team Leader.
This is to ensure all teams and analysts are accountable for timely client communication
and provide visibility to Team Leaders.
11
6. Incident Prioritisation
Overview
The Category selected in LANDesk for an Incident determines the Incident Type, Escalate
To Group and Response level for that Incident.
It is important that the correct Category is selected.
Categories, Incident Types, Escalate To Groups and Response levels are reviewed
regularly. If this information needs changing, please notify your Team Leader.
If the Category in an incident needs to be changed, this can be done by any analyst. This
will automatically update the Incident Type, Escalate To Group and Response level fields
to the new category selected within that incident.
Prioritising by Incident Type
A suggested guide is to attend to jobs in the queues in LANDesk in the below order unless
advised otherwise by your Team Leader.
It is important to remember we cannot always control how long it takes to resolve an
incident or request but we CAN control a timely response to our clients. It is the
responsibility of all analysts to respond to clients within the response level set on all
incidents and requests assigned to them.
Incident
Interruption to a service or degradation to a service used by a client.
Maintenance
Scheduled or Adhoc work related to maintenance and availability
management of production systems.
Request
Information or advice, access to or provisioning of a service for a client.
12
7. Teaching space & High Priority VC calls procedure
Applies to
Every interaction that affects a teaching space
Aim
To keep teaching time loss to a minimum through assisting the client and
providing high priority attention to the incident.
If anything is not clear or you have any questions please contact your Team Leader
immediately as Teaching issues are priority 1 and must be attended to asap.
Service Desk Procedure
1. Calls received or alerts generated by RMS and/or TMS
Attempt to resolve the incident using KBs and knowledge gained by experience
2. Log incident with the following information
Summary Line:
Teaching space – Campus – building - room – Brief description of issue.
Details - as per the call script, ensure you include all relevant details and notes on
troubleshooting performed.
3. If you are unable to resolve the issue at first response, advise the caller we will attend
as soon as possible and follow the steps below to organise a response.
4. Ensure the correct category is selected - Teaching Space Technology.
This should be a priority incident with a 15 minute response time.
DO NOT override and change the response time for teaching incidents.
Check the Service Desk Notes below for assistance with first response troubleshooting
5. Contact a Service Desk support person on the relevant campus and assign the
incident to that person. Once you confirm that someone is responding to the incident,
advise the client (if possible) that someone is on their way.
If you are unable to contact a relevant support person advise the Service Desk Queue
manager or Team leader.
Check the Service Desk Notes below for further information.
6. Click on the Response button in LANDesk and record details of who has been
advised and who will be attending the call,
E.G “Daniel has been advised and is attending the call”.
6a. If the issue is resolved and the room is back in normal working order then resolve
the incident, ensuring that you add detailed notes to the resolution.
6b. If the issue cannot be resolved by the first support person
- If a workaround has been put in place and a return visit to the classroom by
Service Desk is required, please ensure you advise the Service Desk team of the
issue, workaround and expected ETA for resolution.
- Add notes as to what you did with troubleshooting and any relevant information to
assist the next person who will be looking at this job.
13
- Contact the Service Desk queue manager with the incident number and they will
contact the relevant tier 2 team member and assign the incident to that person.
(or tier 2 TL if required)
- If equipment in the room is not working that may affect the next class, fill in and
place the Teaching space issue sign in a prominent place on the desk in the
room where the lecturer will see it. Ensure the queue manager is aware you have
placed a sign in the room.
- If notice is provided that a room will be non functional, the queue manager is to
ensure the Service Desk timetabling liaison person advises the Timetabling unit
of the issue, expected impact and ETA for repair. This will assist in scheduling
and provide an opportunity for affected classes to be relocated.
6c.
If a Hotswap computer is used
- Take the faulty machine to a Personal Computing team member on your campus.
If none are available, place it on their desk with a note stuck to it saying “Faulty
AVT” and the building/room number where you left the hotswap.
- Change the incident status to With 3rd Party and reassign the incident to the
person responsible for repairing the computer (ensure all troubleshooting notes
and time spent have been added as required), and advise the Service Desk
queue manager.
Service Desk Notes
1. All Service Desk staff can see and monitor progress on the priority jobs in our
LANDesk dashboard.
Check to see if there are already incidents logged about the room when taking the call.
If multiple incidents have been logged about a particular classroom or issue, contact
the Service Desk queue manager.
2. To make it easier to check the high priority incidents queue for issues already logged,
ensure the summary line reads as stated in point 2 of the Service Desk Procedure.
Teaching space – Campus – building – room – brief description of issue.
3. Be aware that turning the whole system off and back on again has a high probability of
resolving the issue but will not assist in identifying the underlying cause. The job may
need to be escalated to the relevant support team so the cause can be identified and
repaired. If you are unsure, ask the Service Desk queue manager for advice.
4. DO NOT DELAY in responding to teaching call outs. If all Service desk staff on your
campus are going to MT/lunch together you must take the AV phone with you.
a. If you are on a Service Desk call and an AV issue/call comes through for your
campus and there is no one else available to attend immediately, please advise
your caller that you have an urgent teaching support request that you must attend.
b. Ensure you have their contact details and advise them you will call them back as
soon as you return or if they prefer they can be transferred to another operator.
c. Make sure you call them back as soon as you can if that is the option they selected.
If you transfer the call, quickly give your colleague as much info as you can. You
should only transfer to another person directly. Don’t transfer caller back to the
queue.
14
Personal Computing Procedure
Important: Attend to all high priority teaching space incidents that have been escalated to
you straight away.
IF a Hotswap PC is put in place by Service Desk:
1. Service Desk will give the faulty AVT machine to Personal Computing; reassign the
incident to that person. and change the incident status to With 3rd Party.
2. Once the faulty machine has been fixed, Personal Computing will take it back to the
teaching room and ensure the room is back in normal working order
3. Return the hot swap machine to Service Desk team
4. Check RMS has been updated and fault cleared
5. Close the incident with notes in the resolution window as to what was done to fix the
faulty PC
Attending Teaching Room issues:
1. If the issue is resolved and the room is back in normal working order then resolve the
incident with notes on what you did to fix it in the resolution window.
2. If you have put a Hot Swap PC in place as a workaround, change the incident status to
With 3rd Party. Follow from step 2 above.
3. If the issue cannot be resolved straight away and the room is not in complete working
order:
-
Advise Personal Computing Team Leader immediately. The PC TL will advise
Service Desk TL or queue manager if timetabling is to be contacted if the room is
going to be not operational.
-
Fill in and place the Teaching space issue sign in a prominent place on the desk in
the room where the lecturer would log on.
-
Add a note to the incident of what the issue is and what troubleshooting you have
done
-
Change status of incident to with 3rd party and put in the summary what work
around may have been put in place or if the issue has been escalated to Pro AV
15
Document Revision
Date
11/1/11
Revised By
Julianne Harper
Position
Team Leader – SD
4/4/11
Julianne Harper
Team Leader – SD
10/5/11
11/04/12
Brian Roberson/
Julianne Harper
Vicki Brown/
Julianne Harper/
Matt Barlow
Vicki Brown/
Julianne Harper/
Matt Barlow/
John Roberts
Vicki Brown
Director – CSM
Team Leader - SD
Manager – CSM
Team leader – SD
Team leader - CSM
Manager – CSM
Team leader – SD
Team leader–CSM
Team leader – SD
Manager - CSM
15/10/12
Vicki Brown
Manager - CSM
29/09/14
Vicki Brown
Manager Client Services
26/10/11
4/11/11
Revision Details
Merged the “Incident Ownership and Communications
Policy” document into this document.
Updated the AV/VC Procedure
Updated wording and Process Flow
Updated with Customer process
Updated changes to processes after LANDesk
upgrade.
Update changes to notes process and time spent,
Changed references from customer to Client
Updating response process
Update wording to reflect new DIT structure and
corrections and updates to process
16