ITSM

INCIDENT USER GUIDE

&

(Best Practice)

Prepared by: Jacky Frew

Section: Integrated Help Services

Date Created: 10th November 2008 

Version Control
October 2008 Version 1.0 Jacky Frew
December 2008 Version 1.1 Jacky Frew
September 2009 Version 1.2 Jacky Frew – Incident Type
October 2009 Version 1.3 Jacky Frew – Reject, Due Date, Resolution, Feedback

Created by Jacky Frew Page 1 12/10/2009

 TABLE OR CONTENTS

ITSM INCIDENT DASHBOARD OVERVIEW .................................................................................................. 4 

ITSM INCIDENT OVERVIEW .......................................................................................................................... 5 

CLIENT INFORMATION ................................................................................................................................. 6 

SUMMARY & DESCRIPTION ............................................................................. Error! Bookmark not defined. 

CLASSIFICATION - TYPE .............................................................................................................................. 6 

CLASSIFICATION – Category, Service, Component................................................................................... 6 

SOURCE ......................................................................................................................................................... 7 

PRIORITY........................................................................................................................................................ 7 

TEAM & OWNER ............................................................................................................................................ 7 

SERVICE LEVEL AGREEMENTS (SLA’) & Escalations .............................................................................. 8 

STATUS .......................................................................................................................................................... 8 

IMPORTANT INCIDENT NOTES .................................................................................................................... 9 

CLIENT INFORMATION: .......................................................................................................................................................................................................................9 

CLASSIFICATION - Category, Service, Component: ............................................................................................................................................................................9 

TEAM & OWNERSHIP: ..........................................................................................................................................................................................................................9 

PRIORITY: ..............................................................................................................................................................................................................................................9 

SERVICE LEVEL AGREEMENTS- SLA’s: ............................................................................................................................................................................................9 

STATUS: ................................................................................................................................................................................................................................................9 

GENERAL INCIDENT NOTES ...................................................................................................................... 10 

INCIDENT WITH MULTIPLE REQUESTS: .........................................................................................................................................................................................10 

TASK TOOLBAR: .................................................................................................................................................................................................................................10 

LOGGING of INCIDENTS: ...................................................................................................................................................................................................................10 

NO TASK REQUIRED:.........................................................................................................................................................................................................................10 

TAKE OWNERSHIP BUTTON: ............................................................................................................................................................................................................10 

SAVING INCIDENTS: ..........................................................................................................................................................................................................................10 

RESOLUTION TEMPLATE – recommended example: .......................................................................................................................................................................10 

UPDATE JOURNAL BUTTON: ............................................................................................................................................................................................................10 

ITSM INCIDENT TAB OVERVIEW ............................................................................................................... 11 

TASKS .......................................................................................................................................................... 12 

CREATE AN INTERNAL TASK: ..........................................................................................................................................................................................................12 

CREATE AN INTERNAL TASK(Continued): .......................................................................................................................................................................................12 

Created by Jacky Frew Page 2 12/10/2009

 INTERNAL ASSIGNMENT of a TASK: ................................................................................................................................................................................................13 

ACCEPTING a TASK: ..........................................................................................................................................................................................................................13 

FORWARDING a TASK: ......................................................................................................................................................................................................................13 

REJECTING a TASK:............................................................................................................................................................................ Error! Bookmark not defined. 

TASK ACTIVITY LOG: .........................................................................................................................................................................................................................14 

TASK NOTES: ......................................................................................................................................................................................................................................14 

COMPLETING a TASK: .......................................................................................................................................................................................................................14 

RECORDING TIMES: (Optional) .........................................................................................................................................................................................................14 

JOURNAL: ............................................................................................................................................................................................................................................15 

INCIDENT RESOLUTION ............................................................................................................................. 15 

CLIENT FEEDBACK ..................................................................................................................................... 16 

INCIDENT TAB NOTES ................................................................................................................................ 17 

ATTACHMENTS:..................................................................................................................................................................................................................................17 

PROBLEMS:.........................................................................................................................................................................................................................................17 

ESCALATIONS: ...................................................................................................................................................................................................................................17 

HISTORY: .............................................................................................................................................................................................................................................17 

BILLING INFORMATION: ....................................................................................................................................................................................................................17 

ITSM KEYBOARD SHORTCUTS ................................................................................................................. 17 

ITSM HELP ................................................................................................................................................... 17 

ITSM FAULTS & REQUESTS....................................................................................................................... 17 

AREA SPECIFIC ........................................................................................................................................... 17 

INCIDENT REPORTS ................................................................................................................................... 18 

ITSM REPORTS:..................................................................................................................................................................................................................................18 

Created by Jacky Frew Page 3 12/10/2009

ITSM INCIDENT DASHBOARD OVERVIEW ITSM Roles:
Your role has permissions, views and actions in ITSM.
Available roles include:
Quick access to Dashboards: Administration Service Desk Analyst
Incident, Problem & Reporting Incident Manager Problem Manager
Technical Staff Technical Secure
Billing Computer Systems Officer – CSO

View Dashboards of:

Incidents
Internal Tasks
External Tasks – N/A
Graphing & Reports
Incident status

Global QuickActions

Searches by:
Any field
in ITSM Colours of Grids:
Incidents coloured Red are incidents with
uncompleted Tasks and are not ready to resolve

Incidents coloured green are incidents with

completed or zero tasks and are ready to resolve
Quick Searches
Incidents coloured white are self service and yet
to be classified by the IT Helpdesk

Created by Jacky Frew Page 4 12/10/2009

 ITSM INCIDENT OVERVIEW
Incident, Problem & Reporting Dashboards

Task Count Status Priority

ITSM Quick Actions:
New Incident
Find Incident
Link Incident Client Information:
e.g. name, phone etc.

Classification:
Type
Category
Service Incident Team & Owner
Component
Further Detail
Primarily used by Comms Admin team – (Optional)

Global Quick Actions: Quick Action Buttons

Print Incident etc… Incident SAVE button

Incident Tabs:
Quick Searches: Tasks
Resolution
Feedback
Billing Info History:
Incident Billing This an audit trail of entries and actions by the system and
Problem technical staff.
Journal
Attachment
Time/Date Stamp
History

Created by Jacky Frew Page 5 12/10/2009

CLIENT INFORMATION CLASSIFICATION - TYPE
*Compulsory Select Type from the drop-down list.
Fault - any event which is not part of the standard operation of a service and causes, or may cause,
an interruption to, or a reduction in the quality of service.
Some examples are:
• Network/Email is unavailable or slow
• On a new incident, enter the client’s username and click or tab to locate the client’s name
• Computer will not boot up or Software will not open
• On an existing incident, click to view the Client record
Service Request - is a service extension.
• When typing a known username, tab out of the field to populate the client’s information Some examples are:
• Request for Information or assistance
• You can also type the first 3 or 4 letters of the username and click . Check the information with • Request to install hardware or software
the client to ensure it is correct. • Request to change a password
• Request for a new telephone
• ITSM will automatically populate the client’s username, full name, email, phone and location.
Project – (excluded from SLA), is to record project work.
• All the above fields are compulsory and must not be left blank. You can update the fields, but any Some examples are:
changes made are only kept for that incident. • Scheduled upgrades to systems/services
• Record projects and phases
• If the client has another number to be contacted on then, type this into the field by the QUT phone
number provided. Procurement – (excluded from SLA), is any purchasing required by the client.
Some examples are:
• PC Rollover or Software purchase
• Scheduled/Ad Hoc Hardware Purchase

SUMMARY & DESCRIPTION CLASSIFICATION – CATEGORY, SERVICE, COMPONENT

Unable to connect to network - Lvl 5, KG library, Port, D310 B07-08

• Type in the summary, make it meaningful describing the fault or service request required
• Type a more detailed entry of the fault/service request described by the client and including any
useful information i.e. QUT asset number, PC name, printer name etc.
• Use consistent, meaningful and client friendly terminology
• Describe symptoms, error messages, reoccurring issues and any initial tests performed
* Compulsory fields
Select drop down lists for Category, Service and Component the appropriate selection or best fit.
Not a compulsory field
Further Detail is not a compulsory field but you can make an appropriate selection if required.
NOTE: This field can be blank, so no selection is required.

Created by Jacky Frew Page 6 12/10/2009

SOURCE
* Compulsory field
The source field describes how the incident was reported, such as e-mail or phone etc...
The source by default is Phone. If you would like to change this, select the drop down arrow and
highlight your selection in the list.
TEAM & OWNER
* Compulsory fields
TEAM: This field is defaults the team of the person who logs the incident
Example: IT Helpdesk, CSI etc...
OWNER: This field defaults to the person who logged the incident and team member.
Example: Jacqueline Frew, who is a member of the IT Helpdesk team, logged this incident.
Important:
Incident TYPE (Service Request or Fault) also determines ownership.
Incident Faults – All faults are to be reported, recorded and owned by the IT Helpdesk. No other
service provider can own an incident fault only the IT Helpdesk and 2nd level support can resolve
incidents by moving the status to RESOLVED.
Incident Service Requests – All IT support staff can record and own a service request, including
incident resolution. However, if an incident service request is reported and recorded by the IT Helpdesk
they will maintain the ownership and can resolve the incident by moving the status to RESOLVED.
Created by Jacky Frew Page 7
PRIORITY
* Compulsory field
Priorities implemented in ITSM:
The initial priority is determined at the discretion of the IT Helpdesk, or support staff member logging
the incident. The default priority is MEDIUM and should be reassessed by 2nd or 3rd level support
when a task is assigned.
When determining a priority, consider the following descriptive guide that is used by fire fighters, as
they cannot respond to every fire in the same way.
Example: 1 building as opposed to multiple buildings, in other words, impact to QUT Business.
Also QUT specific points are listed below to assist correct selection of the priority.
LOW - This priority means responding using standard operating procedures and as time allows.
MEDIUM - This priority means responding using standard procedures and operating within normal
supervisory management structures.
HIGH - This priority means technicians respond immediately, assess the situation, may interrupt
other staff working low or medium priority jobs for assistance.
CRITICAL - This priority means an immediate and sustained effort using all available resources until
resolved. On-call procedures activated, vendor support invoked and describes how the IT
organisation will respond taking into account any service catalogues and service level agreements.
NOTE: Default is MEDIUM; you can select another priority if required.
12/10/2009
SERVICE LEVEL AGREEMENTS (SLA’) & ESCALATIONS
Status=Responded 50% resolution time 75% resolution 90% resolution
time time
LOW=4 MEDIUM=3 HIGH=2 CRITICAL=1
Escalations will occur at the following elapsed times or status and initiate an email to the incident owner.
This will also be visually available in the Incident as a colour coded bar.
Escalations in ITSM are calculated from the time the request is in an ACTIVE status until it reaches a
RESOLVED status. The escalations are associated with one standard SLA until Service Level
Management module is implemented and as such resolution times are a guide only.
NOTE: The Standard SLA for QUT is for business hours only - 8am to 6pm Monday to Friday outside
these hours will not be included. There is only one global SLA for QUT outlined in the table below.
Time is calculated between creation and resolution of the incident.
Status = Responded – Escalation to owner if Incident has not been responded to in set time period
50% of Resolution time – Escalation to Incident owner when 50% of resolution time has elapsed.
75% of Resolution time – Escalation to Incident owner when 75% of resolution time has elapsed.
90% of Resolution time – Escalation to Incident owner when 90% of resolution time has elapsed.
100% of Resolution time – Status = Resolved. Escalation to Incident owner
NOTE: The SLA and escalations are on the incident only, not the task.
Created by Jacky Frew Page 8
STATUS
DRAFT - This status is used by Self Service and the status is only viewable by the client prior to
entering their request details and selecting the Submit button. On Submit the status will then move
to Logged and owner as Self Service.
LOGGED - This is the status before an Incident has been classified and saved. This is also the
status used by Self Service when logged by the client and prior to IT Helpdesk classification of the
Self Service request. For self service requests only, this will initiate the start of the SLA.
ACTIVE – This is the status when an Incident has been created and SAVED. This will then occur
automatically and move the status from Logged to Active. This status also initiates the start of the
Service Level Agreement (SLA) and the escalation process.
RESPONDED - The Incident will automatically move to this status when the first associated task is
accepted. However, if the Incident has no associated task(s), then the status can manually be
changed to Responded.
WAITING - Status used when technical support staff are waiting on hardware, software, Request
for Change (RFC), feedback from client, etc. generally anything that could be considered beyond
their control. Documentation of the reason is required in the Journal or Task. This will stop the
progression of the Service Level Agreement (SLA) and the escalation process.
INVESTIGATE - This status is only to be used if the Incident Manager or system as follows. If the
resolution of an Incident is unsatisfactory and the client response is NO. The system will
automatically move the Incident from Resolved to Investigate status. If support staff are unable to
classify an Incident, or for any reason are impeded in responding to, or the resolution of an Incident
and require the Incident Manager to investigate.
RESOLVED - This status initiates a resolution email to the client for sign off of an Incident. An
Incident that is a fault can only be moved to this status by the IT Helpdesk or 2nd level support as
they are the owners. An Incident that is a service request can be moved to this status by the owner
of the Incident. The Resolved status is the point when the Incident Service Level Agreement (SLA)
and the escalation process will stop.
CLOSED – This is the final status when the customer signs off an Incident or provides a YES
response. If there is no feedback received from the customer in 5 days, the Incident will
automatically move to a closed status.
12/10/2009
IMPORTANT INCIDENT NOTES
CLIENT INFORMATION:
Client information should include the following:
• Confirmation from the client that their details are correct
• Change email address if applicable i.e. external address
• Include another contactable phone number if possible
• Confirm clients location details
• Confirm client’s availability i.e. may work only Tuesday and Thursday
• Update or record necessary client information and SAVE the incident
TEAM & OWNERSHIP:
Important:-Incident TYPE (Service Request or Fault) also determines ownership.
Incident Faults – All faults are to be reported, recorded and owned by the IT Helpdesk. No other
service provider can own an incident fault only the IT Helpdesk and 2nd level support can resolve
incidents by moving the status to RESOLVED.
Incident Service Requests – All IT support staff can record and own a service request, including
incident resolution. However, if an incident service request is reported and recorded by the IT Helpdesk
they will maintain the ownership and can resolve the incident by moving the status to RESOLVED.
Important:-– All incidents that are more than 1 month old and still remain in the IT Helpdesk queue will
be moved to the service providers queue for actioning. This will occur at the beginning of each month.
SERVICE LEVEL AGREEMENTS- SLA’s:
The Standard SLA for QUT is for business hours only - 8am to 6pm Monday to Friday outside these
hours will not be included. There is only one global SLA for QUT.
Important:-– Incident Types – Procurement and Project are excluded from SLA’s.
Escalation notifications
The incident owner will receive notifications when the incident reaches the following:
• Responded
• 50% of resolution time
• 75% of resolution time
• 90% of resolution time
• 100% of resolution time
Created by Jacky Frew Page 9
CLASSIFICATION - Category, Service, Component:
Select the correct or nearest classification. If you are unable to classify the incident then:
• Select - unable to classify for Category, Service, Component
• Move the incident to Investigate status and SAVE
• Create a task for the incident manager who will then classify to nearest classification.
PRIORITY:
• The initial priority is determined at the discretion of the IT Helpdesk, or support staff member
logging the incident. The default priority is MEDIUM and should be reassessed by 2nd or 3rd
level support when a task is assigned.
• When determining a priority, consideration should be given on the impact to QUT Business,
VIP or clients ability to work and the type of work required for example:
- Lecture being given, a number of Lab machines not functioning, client leaving for overseas,
tender or purchase deadline required etc.
STATUS:
The following are included: Draft, Logged, Active, Responded, Waiting, Investigate, Resolved and Closed.
Important:
WAITING - Status used when technical support staff are waiting on hardware, software, Request for
Change (RFC), etc.
INVESTIGATE - This status is only to be used if the Incident Manager is required to investigate or
automatically by the system if the client provides feedback that is required to be followed up.
RESOLVED - The resolution email to the client for sign off of an Incident. An Incident that is a fault
can only be moved to this status by the IT Helpdesk or 2nd level support as they are the owners.
CLOSED – This is the final status when the customer signs off an Incident or if there is no feedback
received in 5 days.
NOTE: No IT Support staff should use the Closed status as this prevents the client from providing
feedback. Quick Close should also not be used for this reason.
12/10/2009
GENERAL INCIDENT NOTES SAVING INCIDENTS:
INCIDENT WITH MULTIPLE REQUESTS: Important: Points to note on saving incidents as follows:
Multiple requests logged in one incident should be separated and a new incident logged for each • You must SAVE an incident before you create a task or the client information will not be saved.
request as follows:
• When you have created a task, added a journal entry or generally made any change then, you
Example: need to SAVE the incident.
One incident logged to rebuild 10 machines, should have a separate incident logged for each. This
would mean there would be 10 incidents in total. RESOLUTION TEMPLATE – recommended example:
{greeting}
TASK TOOLBAR:
Hi John,

{resolution containing advise, action taken, further info etc}

• New icon I've checked your status in the system, and it appears you don't have a current contract registered
with the HR department. Your last contract finished on the 24/8/08.
• Refresh icon
• Print icon Without a current contract, you will not be able to access QUT Virtual. If you have submitted a new
• Forward and Back icons contract for processing and you need to enquire on its status, or if you need to submit a new
contract, you should contact the HR department on 3138 4104 or speak to your supervisor.
• Form or Grid view icon
• Group By box If you have any further queries, please don't hesitate to contact us again.
Important: If you receive a task for example the Accept button is not visible then, select the refresh
{sign-off including name and section (optional department) }
button and the button will reappear. This is a known bug in ITSM.
Regards,
LOGGING of INCIDENTS: Hieu Vu
QUT IT Helpdesk
If the incident is a service request then, you do not have to advise the client to contact the IT Helpdesk
Integrated Help Services 
to log the request. You can log the request yourself.
If the incident is a fault then, all faults should be reported and recorded by the IT Helpdesk with the UPDATE JOURNAL BUTTON:
exception of 2nd level support (Tech Sup Teams) as they have the same rights as the IT Helpdesk.
If you select the button on the incident screen then, you will receive the
NO TASK REQUIRED: following popup window.
If you are able to resolve the incident and no task is required to be created then:
• Complete the resolution
• First Call Resolution? = YES
You can make a quick update to the journal. However, it will only show a summary in the journal
TAKE OWNERSHIP BUTTON:
grid view of “Quick Update” and no detail.
You can take ownership of an incident by selecting button.

Created by Jacky Frew Page 10 12/10/2009

ITSM INCIDENT TAB OVERVIEW

Incident Tabs:

DESCRIPTION of INCIDENT TABS:

TASKS: Create an internal task to manage work for yourself or if you require assistance from another technical support team to resolve the incident.
RESOLUTION: Resolutions must be completed when either all tasks have been completed or you have resolved the incident with no task.
FEEDBACK: This is where client feedback is recorded
BILLING INFO / INCIDENT BILLING: This is only viewable and used by areas that require billing information to be recorded e.g. Comms Admin etc.
PROBLEM: This is used to link the incident to a problem and to view a problem that has been linked to the incident.
JOURNAL: This is used to record and send client information e.g. emails, follow up phone calls or information useful to staff in resolving the incident.
ATTACHMENT: This is used to attach files to the incident that may assist support staff in resolving the incident e.g. screenshots, error message etc.
TIME / DATE STAMPS: Escalation process and notifications due to be sent for this incident, (does not indicate they have been sent). Also shows creation, resolution dates etc.
HISTORY: This is where you can view the audit trail of an incident e.g. date and time stamps, change made to the incident by staff etc.

Created by Jacky Frew Page 11 12/10/2009

TASKS CREATE AN INTERNAL TASK(Continued):
CREATE AN INTERNAL TASK:
NOTE: It is important to SAVE the incident before you create a task.

If you are unable to resolve the incident at first point of contact then you will need to create a task and
assign to a support team as follows:

NOTE: External tasks are not used by the majority of teams in QUT, mainly internal.

You will now need to complete the Summary and Description fields.
SUMMARY: Type in a short summary of the work required.

DESCRIPTION: Type in the description any information, tests performed or details etc. that may be
• By default the task tab will be viewable useful to support team members in completing the task or the resolution of the incident.

• Select →New →Internal Task

• You can also use the button on the incident form however; this will
populate the task with the summary and description from the incident form.

• You can also use the button, but this is only if you wish to create a task
for yourself not a team. This will populate with all incident information as above including, your
team, assignee, phone, email and status to accepted etc.

NOTE: The final stage is to select SAVE on the incident form. This is very important as it will
automatically forward the task and the notification to the assigned team.

• Select the team you would like to assign the task to by using the drop down arrow and type the first
letter, this will display teams beginning with this letter.
• The Task Email field will automatically populate with the team or daily event coordinator (DEC)
address.
• You are only required to assign to a Team not a Team Subgroup or an Assignee.
• All other fields required at this stage are automatically populated with the current incident
information.
• The task count will now be 1 as shown on the incident form and coloured
red indicating the task will need to be completed before it can be resolved.
• If you require work to be done by more than 1 team then follow the previous steps to create
more tasks. You will also note the task number will change on the incident form indicating the
number of tasks for that incident.
• Remember to SAVE the incident following the creation of each task.

Created by Jacky Frew Page 12 12/10/2009

INTERNAL ASSIGNMENT of a TASK: ACCEPTING a TASK:
NOTE: This is generally assigned by daily event coordinators (DEC’s) or by team leaders. NOTE: Before you do anything with a task e.g. forward, complete etc. you need to Accept the task
first and SAVE on the incident form.
• Go to the incident dashboard by selecting the icon on the incident form.
• When you have selected the button, the button will no longer be viewable in the
task window. The task status automatically moves to accepted and greys out the team,
• Select the tab, the default view will show This is a assignee etc. fields. The incident status will automatically move to Responded.
list of tasks that have been assigned to you and are incomplete.
FORWARDING a TASK:
• Select the drop down arrow to display a list as shown below and select My Teams Unassigned
Tasks • There may be reasons why you need to forward a task e.g. leave, incorrectly assigned and
should go to another team etc. A forwarded task can no longer have notes added.
• The following dashboard grid will appear showing the status as waiting
• Select the button
• The popup window below will appear and you need to enter a reason why you are forwarding
with useful information for the team you are forwarding to. You cannot leave this blank, then
click OK.
• Select a task and double click. This will open the incident and you can view the task grid as above.
You will need to double click on the task in the grid that you want to open.
• To assign a task to a Sub Team select drop down arrow and select your team

• To assign to a team member, select drop down arrow and the team member • Another popup window will appear as below and you will need to select a team to forward the
task to. Select OK and SAVE on incident form.

• The assignee information will automatically be populated with their phone number and email
address.
• When you have completed these steps SAVE the incident on the incident form and the assignment
of the task will be completed.

NOTE: If you do not have a Sub Group then assign the task to a team member for actioning. If the task
is not assigned to an individual it will remain in the team’s unassigned queue.

Some teams may not have a daily event coordinator (DEC) or team leader to assign tasks. In this
instance the whole team my monitor the unassigned queue and assign tasks to themselves.

Created by Jacky Frew Page 13 12/10/2009

TASK ACTIVITY LOG:
NOTE: The task activity log has an audit trail for the task only. The activity log will automatically record;
date, time, team, assignee, forward, reject, accept, complete, usernames, details etc. for this task only.
The task activity log, will also record any task notes added and if an email has been sent to a support
staff member.
TASK NOTES:
NOTE: A task note can be entered at any time by any support staff member to provide information.
Some examples listed below:
• Provide the owner of the task with more information
• Owner of the task requires recording work in progress
• Client contact, testing preformed, versioning of software etc.
• Information to assist in resolving the incident, as there may be more than one task.
SUBMIT: Type in the note you would like to submit. Select Submit and then SAVE the incident. This
will place the note in the task activity log automatically for support staff to view.
EMAIL: Type in the note you would like to email to the task owner. Select Email and then SAVE the
incident. This will automatically send an email to the task owner and place an entry in the activity log.
Important: You must select Submit or Email and then SAVE the incident for the action to happen.
Created by Jacky Frew Page 14
COMPLETING a TASK:
NOTE: A task can only be completed when the following is confirmed:
• The incident is ready to be resolved e.g. the fault has been fixed or the service request has been
completed.
• A documented record should be included as a task note to advise of the work actually done and
submitted to the task activity log prior to selecting the complete button.
• The task note should include useful information to other support staff, as a client may require an
update or to reopen the incident.
• There may be more than one task and the information needs to be helpful to support staff with
the other tasks for this incident.
• Optional – You have made contact with the client to confirm their fault has been fixed or service
request completed. This can be done by phone or email from the journal.
• Optional – Hours of Work, Estimated Effort and Actual Effort are required to be recorded.
This must be entered before you select the Complete button and SAVE the incident.
RECORDING TIMES: (Optional)
NOTE: If you are required to complete times for estimated or actual effort then, this must be entered
before you select the Complete button for the task and SAVE the incident.
Estimated Effort – Estimated time spent on the task
Actual Effort – Actual time spent on the task
NOTE: Technical Support teams (2nd level), are only required to record actual effort. For example a
time block of 15 minutes would be entered as .25
12/10/2009
JOURNAL: INCIDENT RESOLUTION
NOTE: A journal entry can be made by any support staff member at any time prior to the incident NOTE: The incident resolution can only be completed when all the tasks have been completed.
reaching a CLOSED status. Generally, the journal is used for the following: Alternatively, you can resolve an incident that has no tasks. Follow the steps below to resolve an
• Record an email received from a client. incident:
• Send an email to the client for further update or if the client is not contactable to confirm the fault or
service request has been resolved.
• Useful information for support staff, especially if there is more than one task for an incident. * Compulsory fields
• Recording any client interaction concerning the incident. • Select the resolution tab
• If required, change the classification from the original incident if the fault or request was
classified incorrectly. All fields must be completed, apart from the Resolution Further Details
field as this is optional.

*
• To make a Journal entry. Select the Journal tab → Journal Notes *
*
• Enter a Summary and the Note you would like to record as shown below and SAVE the incident.

• The cause code field is optional you can make a selection from the drop down menu and select
the best fit.

• If you intend to send an email from the journal to the client then, you must address it like an email • Complete the First Call Resolution? If the incident has a task then, first call resolution = NO
and provide your contact information or signature so the client can contact you if required.
*
• To send an email select the button and then SAVE the incident.
• Following the saving of the incident the journal status will automatically be updated as shown below.

NOTE: You can also make a Secure journal note. This journal note will only be viewable to members of
your team.

Created by Jacky Frew Page 15 12/10/2009

INCIDENT RESOLUTION – (CONTINUED)
The incident resolution is an email that is sent to the client. The fields in the grey area will be
automatically populated from information provided in the incident.
• Enter the resolution text. This should be in a client friendly language, advising the client of action
taken that includes a signature sign off with your contact details.
*
• If you select the Workaround then, it is only valid for this incident.
• SAVE the incident
NOTE: You must complete all the compulsory fields before the incident can be resolved.
Important: An Incident - fault can only be moved to a Resolved status by IT Helpdesk or 2nd level
support, (CSO’s).
If you are not a member of above support teams e.g. service provider or 3rd level support then, you must
complete the resolution and save, but do not move the status to Resolved.
When the status has been moved to Resolved and saved, an email will automatically be sent to the client
requesting sign off.
Created by Jacky Frew Page 16
CLIENT FEEDBACK
NOTE: If the client responds NO to the resolution. The incident will automatically move to
INVESTIGATE status.
• The incident manager will receive an email containing the client’s response.
• The incident manager will open the incident and read client feedback under the resolution tab.
Also, the incident manager will view original request, task and journal entries, including the
resolution provided.
• The incident manager will then contact the client to confirm there is still a problem also advising
the incident will be reopened and the service provider will be contacted.
• The incident manager will record all client interaction in the journal. If the client is not
contactable by phone then, the incident manager will send the client an email from the journal
advising of steps taken.
• The incident manager will then create a new task and assign to appropriate service provider
requesting client follow up required.
• The service provider upon accepting the task, will document any client interaction in the journal
so the incident manager has a record of steps taken to resolve the incident.
• When the service provider has completed the task, the incident manager will then read all
entries and determine if the incident can now be moved to a Closed status.
Important: Quick Close on the navigator bar or moving an incident directly to Closed status is not
allowed. This does not allow the client to provide feedback.
• An incident can only move to a Closed status by; client sign off, incident manager following an
investigation or automatically by the system if the client does not sign off in 5 days.
12/10/2009
INCIDENT TAB NOTES ITSM KEYBOARD SHORTCUTS
ATTACHMENTS: CTRL + C Copy’s selected/highlighted text
NOTE: There are no restrictions for attachments. Any file type or size can be attached. Useful for CTRL + V Paste contents
screenshots or emails with complete headers etc. CTRL + S Save Incident/Problem
• Select the Attachment tab → New Attachment CTRL + w Open a New ITSM Main Window
• Browse to locate the file and attach CTRL + G Search Incident ID and Problem ID
• You can attach multiple files by repeating the steps. CTRL + N New Incident/New Problem
SHIFT + F1 Incident Workspace/Dashboard
SHIFT + F2 Problem Workspace/Dashboard
F5 Refresh
F1 ITSM Help
PROBLEMS:
ALT + Å Back to previous screen
NOTE: An incident can be linked to a problem from the Problem tab.
• Select the Problem tab → link icon
• Enter the Problem number if already created ITSM HELP
• Select OK. Important: If you require assistance or training at then, contact the incident manager for assistance.
You will now be able to have a read only form view of the linked problem in the Problem tab and the Incident Manager
incident will automatically be linked. Jacky Frew
Important: You can only link Resolved or Closed incidents to a problem and the resolution of the Phone: 3138 1553
incident should advise the client of the Problem number so they can follow up. Mobile: 0414 864 144
Email: j.frew@qut.edu.au
The resolution of the incident should also include your signature sign off or the incident managers,
providing the client with a contact for updates. Only service providers can create a problem and a
problem cannot be created by another person. ITSM FAULTS & REQUESTS
NOTE: If you are experiencing difficulties or faults with ITSM then, log an incident using the following
ESCALATIONS: classification to the ITSM support team. This also includes service requests i.e. creation of account
Select the Escalation tab to show a history of the escalation process and current notifications sent for the for new staff member.
incident. Category: Server Management
Service: Software
HISTORY: Component: Application
Select the History tab to view the audit trail of an incident e.g. date and time stamps, changes made to Further Detail: ITSM
the incident by staff etc. Team: EIS
0
BILLING INFORMATION:
AREA SPECIFIC
This is only viewable and used by areas that require billing information to be recorded e.g. Comms Admin This user guide can be used by areas to develop a more specific document to meet their
etc. These areas will have their own individual process for billing. requirements or a quick reference guide

Created by Jacky Frew Page 17 12/10/2009

INCIDENT REPORTS
ITSM REPORTS:

ITSM incident reports can be viewed by selecting the reporting icon on the incident or problem form
view.

• You must have access to view the reports. If you do not have access you can log a request to the
ITSM support team.
• You need to enter your QUT Access username, password and authentication is LDAP.
• Select Public Folders then, ITSM Reports.
• Select the area you would like to run a report on.

Created by Jacky Frew Page 18 12/10/2009