itsm incident overview v1.3

18
Created by Jacky Frew Page 1 12/10/2009 ITSM INCIDENT USER GUIDE & (Best Practice) Prepared by: Jacky Frew Section: Integrated Help Services Date Created: 10 th 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

Upload: ed1torz

Post on 10-Apr-2015

133 views

Category:

Documents


0 download

TRANSCRIPT

Page 1: ITSM Incident Overview v1.3

Created by Jacky Frew Page 1 12/10/2009

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

Page 2: ITSM Incident Overview v1.3

Created by Jacky Frew Page 2 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 

Page 3: ITSM Incident Overview v1.3

Created by Jacky Frew Page 3 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 

Page 4: ITSM Incident Overview v1.3

Created by Jacky Frew Page 4 12/10/2009

ITSM INCIDENT DASHBOARD OVERVIEW

Quick access to Dashboards: Incident, Problem & Reporting

ITSM Roles: Your role has permissions, views and actions in ITSM. Available roles include: Administration Service Desk Analyst Incident Manager Problem Manager Technical Staff Technical Secure Billing Computer Systems Officer – CSO

Quick Searches

Searches by: Any field in ITSM

View Dashboards of: Incidents Internal Tasks External Tasks – N/A Graphing & Reports

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 Incidents coloured white are self service and yet to be classified by the IT Helpdesk

Incident status

Global QuickActions

Page 5: ITSM Incident Overview v1.3

Created by Jacky Frew Page 5 12/10/2009

ITSM INCIDENT OVERVIEW

ITSM Quick Actions: New Incident Find Incident Link Incident

History: This an audit trail of entries and actions by the system and technical staff.

Classification: Type Category Service Component Further Detail

Client Information: e.g. name, phone etc.

Incident Tabs: Tasks Resolution Feedback Billing Info Incident Billing Problem Journal Attachment Time/Date Stamp History

Quick Searches:

Global Quick Actions: Print Incident etc… Incident SAVE button

Status Task Count Priority

Incident, Problem & Reporting Dashboards

Incident Team & Owner

Primarily used by Comms Admin team – (Optional)

Quick Action Buttons

Page 6: ITSM Incident Overview v1.3

Created by Jacky Frew Page 6 12/10/2009

CLIENT INFORMATION

• On a new incident, enter the client’s username and click or tab to locate the client’s name

• On an existing incident, click to view the Client record

• When typing a known username, tab out of the field to populate the client’s information • You can also type the first 3 or 4 letters of the username and click . Check the information with

the client to ensure it is correct. • ITSM will automatically populate the client’s username, full name, email, phone and location. • All the above fields are compulsory and must not be left blank. You can update the fields, but any

changes made are only kept for that incident. • If the client has another number to be contacted on then, type this into the field by the QUT phone

number provided.

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 • Computer will not boot up or Software will not open Service Request - is a service extension. Some examples are: • Request for Information or assistance • Request to install hardware or software • Request to change a password • Request for a new telephone Project – (excluded from SLA), is to record project work. Some examples are: • Scheduled upgrades to systems/services • Record projects and phases 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

• 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

CLASSIFICATION – CATEGORY, SERVICE, COMPONENT

* 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.

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

Page 7: ITSM Incident Overview v1.3

Created by Jacky Frew Page 7 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.

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.

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.

Page 8: ITSM Incident Overview v1.3

Created by Jacky Frew Page 8 12/10/2009

SERVICE LEVEL AGREEMENTS (SLA’) & ESCALATIONS

Status=Responded 50% resolution time 75% resolution time

90% resolution 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.

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.

Page 9: ITSM Incident Overview v1.3

Created by Jacky Frew Page 9 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

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.

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.

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.

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

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.

Page 10: ITSM Incident Overview v1.3

Created by Jacky Frew Page 10 12/10/2009

GENERAL INCIDENT NOTES INCIDENT WITH MULTIPLE REQUESTS: Multiple requests logged in one incident should be separated and a new incident logged for each request as follows: Example: 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.

TASK TOOLBAR:

• New icon • Refresh icon • Print icon • Forward and Back icons • Form or Grid view icon • Group By box Important: If you receive a task for example the Accept button is not visible then, select the refresh button and the button will reappear. This is a known bug in ITSM.

LOGGING of INCIDENTS: If the incident is a service request then, you do not have to advise the client to contact the IT Helpdesk 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 exception of 2nd level support (Tech Sup Teams) as they have the same rights as the IT Helpdesk. NO TASK REQUIRED: If you are able to resolve the incident and no task is required to be created then: • Complete the resolution • First Call Resolution? = YES TAKE OWNERSHIP BUTTON: You can take ownership of an incident by selecting button.

SAVING INCIDENTS: Important: Points to note on saving incidents as follows:

• You must SAVE an incident before you create a task or the client information will not be saved. • When you have created a task, added a journal entry or generally made any change then, you

need to SAVE the incident. RESOLUTION TEMPLATE – recommended example: {greeting} Hi John, {resolution containing advise, action taken, further info etc} 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. Without a current contract, you will not be able to access QUT Virtual. If you have submitted a new 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. If you have any further queries, please don't hesitate to contact us again. {sign-off including name and section (optional department) } Regards, Hieu Vu QUT IT Helpdesk Integrated Help Services 

UPDATE JOURNAL BUTTON:

If you select the button on the incident screen then, you will receive the following popup window.

You can make a quick update to the journal. However, it will only show a summary in the journal grid view of “Quick Update” and no detail.

Page 11: ITSM Incident Overview v1.3

Created by Jacky Frew Page 11 12/10/2009

ITSM INCIDENT TAB OVERVIEW

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.

Incident Tabs:

Page 12: ITSM Incident Overview v1.3

Created by Jacky Frew Page 12 12/10/2009

TASKS 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.

• By default the task tab will be viewable • Select →New →Internal Task

• 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.

CREATE AN INTERNAL TASK(Continued):

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 useful to support team members in completing the task or the resolution of the incident. • 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. • 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.

Page 13: ITSM Incident Overview v1.3

Created by Jacky Frew Page 13 12/10/2009

INTERNAL ASSIGNMENT of a TASK: NOTE: This is generally assigned by daily event coordinators (DEC’s) or by team leaders.

• Go to the incident dashboard by selecting the icon on the incident form.

• Select the tab, the default view will show This is a list of tasks that have been assigned to you and are incomplete.

• Select the drop down arrow to display a list as shown below and select My Teams Unassigned Tasks

• The following dashboard grid will appear showing the status as waiting

• 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

• 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.

ACCEPTING a TASK: 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.

• 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, assignee etc. fields. The incident status will automatically move to Responded.

FORWARDING a TASK: • 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.

• 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.

• 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.

Page 14: ITSM Incident Overview v1.3

Created by Jacky Frew Page 14 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.

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

Page 15: ITSM Incident Overview v1.3

Created by Jacky Frew Page 15 12/10/2009

JOURNAL: NOTE: A journal entry can be made by any support staff member at any time prior to the incident reaching a CLOSED status. Generally, the journal is used for the following: • Record an email received from a client. • 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. • Recording any client interaction concerning the incident.

• 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.

• If you intend to send an email from the journal to the client then, you must address it like an email 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.

INCIDENT RESOLUTION NOTE: The incident resolution can only be completed when all the tasks have been completed. Alternatively, you can resolve an incident that has no tasks. Follow the steps below to resolve an incident: * Compulsory fields • 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.

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

• Complete the First Call Resolution? If the incident has a task then, first call resolution = NO

* * *

*

Page 16: ITSM Incident Overview v1.3

Created by Jacky Frew Page 16 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.

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.

*

Page 17: ITSM Incident Overview v1.3

Created by Jacky Frew Page 17 12/10/2009

INCIDENT TAB NOTES ATTACHMENTS: NOTE: There are no restrictions for attachments. Any file type or size can be attached. Useful for screenshots or emails with complete headers etc. • Select the Attachment tab → New Attachment • Browse to locate the file and attach • You can attach multiple files by repeating the steps.

PROBLEMS: 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 • Select OK. You will now be able to have a read only form view of the linked problem in the Problem tab and the incident will automatically be linked. Important: You can only link Resolved or Closed incidents to a problem and the resolution of the incident should advise the client of the Problem number so they can follow up. 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. ESCALATIONS: Select the Escalation tab to show a history of the escalation process and current notifications sent for the incident.

HISTORY: Select the History tab to view the audit trail of an incident e.g. date and time stamps, changes made to the incident by staff etc. 0

BILLING INFORMATION: This is only viewable and used by areas that require billing information to be recorded e.g. Comms Admin etc. These areas will have their own individual process for billing.

ITSM KEYBOARD SHORTCUTS CTRL + C Copy’s selected/highlighted text CTRL + V Paste contents CTRL + S Save Incident/Problem CTRL + w Open a New ITSM Main Window CTRL + G Search Incident ID and Problem ID CTRL + N New Incident/New Problem SHIFT + F1 Incident Workspace/Dashboard SHIFT + F2 Problem Workspace/Dashboard F5 Refresh F1 ITSM Help ALT + Back to previous screen

ITSM HELP Important: If you require assistance or training at then, contact the incident manager for assistance. Incident Manager Jacky Frew Phone: 3138 1553 Mobile: 0414 864 144 Email: [email protected]

ITSM FAULTS & REQUESTS

NOTE: If you are experiencing difficulties or faults with ITSM then, log an incident using the following classification to the ITSM support team. This also includes service requests i.e. creation of account for new staff member. Category: Server Management Service: Software Component: Application Further Detail: ITSM Team: EIS

AREA SPECIFIC This user guide can be used by areas to develop a more specific document to meet their requirements or a quick reference guide

Page 18: ITSM Incident Overview v1.3

Created by Jacky Frew Page 18 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.