Incident management uses a simplified process in ITIL 4. In this article we dig a little deeper in the possibilities you have to meaningfully close a ticket. Moreover, we offer you an acceptable outcome to get rid of all these aged tickets that have been mooching around the Service Desk queues for more than a year.
There are a lot of options at your disposal to mark incidents (and request) as closed. Choosing interesting closure codes can be beneficial for your statistics and success factors. A lot of Service Desk applications make use of 2 common fields to indicate a closed ticket, named “status” and “resolution code“.
Status
Depending on the defined workflow for incidents and requests, the choices for the last status of a ticket are often limited. In general, only 2 statuses are used for this: “closed” and “rejected“.
- Closed: this status indicates that the activities on that ticket are terminated and an eventual resolution has been confirmed by the user. No further actions or comments are allowed or possible on that ticket after it is closed.
- Rejected: when a ticket is rejected, the service desk agent has decided that it is out of the Service Desk’s scope and hence will not be handled further. The rejection of a ticket can happen anywhere in the workflow.
Resolution code
To be able to categorize what actually happened with the ticket, you can define numerous resolution codes. However, it is important that all your service desk agents are aware of the correct usage of this field. Possible resolution codes are:
| Resolution code | Description |
|---|---|
| Resolved | This is the most common (hopefully) resolution code is, when this issue is resolved. |
| Resolved remotely | When you want to have a deeper insight about how the issue is being fixed. Resolved remotely can mean that the issue was resolved by means of remote control software, without a visit to the user’s desk. This can be a metric to measure efficiency at the Service Desk. |
| Resolved (workaround) | When you want to have a deeper insight about how the issue is being fixed. Resolved (workaround) can mean that an issue was fixed with a temporary solution (workaround). This can also be a metric to measure efficiency at the Service Desk or to measure the existing technical debt. |
| Canceled | In many cases users are allowed to change the ticket status themselves. For example when they were able to resolve a ticket on their own. In that case the resolution code could be “canceled”, indicating no further effort is required by IT. |
| Rejected | When the status is rejected, the resolution code is basically identical. No further action is taken, the incident was not accepted. |
| Unable to resolve | Sometimes you just have to admit that the Service Desk with all their knowledge and experience, is still unable to find a solution. This is one of the ways to keep your queues sound. |
Closure lifesavers
You won’t be the first one who notices that certain tickets tend to stay forever in one of the Service Desk queueus. Valid tickets that despite all effort seem unresolvable, or some will need a very long time and a lot of resources to have them completed. In other cases incidents may require infrastructure changes that are beyond the scope of the Service Desk. To avoid this, you can use additional closure codes that tell the user that the life of the incident will continue on another level.
| Resolution code | Description |
|---|---|
| Passed to PRB | In ITIL a problem actually means a root cause of one or more incidents. When a ticket results in a root cause investigation, you can close the incident and open a problem record instead. Don’t forget to link the incident to the problem. |
| Passed to PRJ | Within every IT department, it is very useful to have a clear definition for a project, and a framework for handling them. We speak for example of a project when the amount of estimated mandays is more than 7. Tickets (in this case especially requests) that are estimated to take longer, can be closed and routed to the existing project framework. |
| Passed to RFC | Components of the IT infrastructure (e.g. server hardware, network active components, storage, clients, applications, systems, etc.) that need a change, do commonly require additional steps and checks before implementation. Such changes are handled in the Change Enablement practice. When the resolution requires a Request For Change (RFC), you can pass this to the Change Enablement team. |
In all these “non-standard” cases, the user needs to be informed about why their ticket has been closed, and where they can find the linked PRB, PRJ or RFC record to follow up on their requests.
There is actually no limit in choosing status and resolution codes, and you can combine them as well, but never forget one of the most important ITIL guidelines: always “Keep it simple !“.
How have you organised the (second) last step in your incident management or request management process ? What other suggestions do you have to improve statistics and KPI’s ? I am curious to know, so thanks for sharing.
Categorieën:Team Service Desk
Service Desk Management 
Plaats een reactie