Many, if not most, of the service desks I’ve worked with don’t let end users choose the priority of the incident ticket while they log their issue, but they do trust the end user to select the impact and urgency. Having fewer IT failures that cause high-priority incidents is the obvious (and flippant) answer, but seriously - how can we alter end-user behaviour to make the lives of service desk agents a little easier? What can end users influence? So how can service desks help themselves by reducing the number of high-priority tickets in their queues - allowing them to focus attention on the real priorities? But end users don’t care about this - if they have an IT issue to report, they usually perceive it as high priority. A priority matrix is a useful tool which lets service desk agents assign priority to incident tickets based on their impact and urgency. The default values are shown in the table below.As per ITIL, priority is a factor of impact and urgency, which means that the priority of an incident is determined both by the effect it has on business and the time available for repair (or avoidance) before the incident’s impact is felt by the business. The Priority Values table holds records for all the possible priority values used in the priority matrix, making it faster to set up new priority matrices. Urgencies only appear in requests if the value in the request's Service Priority Group field overlaps with the Available for Priority Group field in the Urgency record. The Urgencies table contains a record for each possible urgency value that can be selected within a request record. The Order field defines the order in which the impact is listed in the drop-down list. Within a request, the available impacts are filtered based on the priority group of the Service for the request being contained in the Impact record's Available for Priority Groups field. Each impact can be made available for one or more priority groups. The Impacts table contains all possible Impact values that can be selected in the request tables. That will make those values available to create the priority matrix. Then, either the existing impact and urgency records can be updated to add that priority group to the available groups, or new impact and urgency records can be created and linked to the new group. In order to set up a new priority group, the priority group must first just be created, named, and saved. For example, the priority matrix for standard service requests has six levels of priority.Īll of the wording in the priority matrix fields is defined for the specific priority group, so it is possible to have completely different priority lists for different services, as needed. They are applied based on the request type and each priority group can have its own set of urgencies, impacts, and priority matrix of values that result from all combinations of urgency and impact within a record. Priority Groups TableĮach service in the Service Portfolio table is linked to a Priority Group.īy default there are six priority groups, but you can create additional ones as needed. This section describes how these tables work. There are five tables that manage the urgency, impact and priority values that are shown within a Service Request, Incident, Change Request, Problem or Release record.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |