How to handle incidents if they are user errors?

Question

Hi,

I am setting up incident management and have a question about how to handle the following scenario:

1. User calls to say they are unable to edit a form.

2. An incident ticket is created and as part of the diagnosis, agent discovers the users did something wrong.

What happens now?  Should we change the incident to a request since this was more or a how do I question?

Or do we just close it and log in an incident post mortem field that this was user error?

What is ITIL Best Practice?

Thanks for your help.

Lindsay

Zita Bagi_1jaqgl · Accepted Answer

Hi,

I think this should depend entirely on what your company / team defines. If you are a service desk agent, probably you cannot decide this question, but your team lead or service manager should know this.

From the user's point of view this was an incident because something didn't work for them.

But if your team registers incidents only for actual technical problems, then you should probably add a Canceled status to the incident and open a general user request.

Iago Docando · Accepted Answer

I would suggest having a resolution similar to "user error" just to be able to tell them appart whrn you need to generate your reports but if you think of it they are regular incidents just like any other. Only after you investigate the causes and come to a diagnostic can you tell "ok, this is the user's fault". To get there you have already went through your incident resolution process.

To me, the incident is such because the user reported it as such. As an example, let's say user A and user B are making the very same mistake. User A doesn't know he's doing somethin wrong, but user B is aware of it but he can't remember the correct steps he had to take in order to achieve the desired result. Both will reach to your service desk but A will report an incident and B will just request from you a direct answer with the propprer steps to take.

Mike Bowen · Accepted Answer

The way I set it up our Jira Service Desk, most request types get logged under a 'Service Request' and they have a pre-defined priority of medium. The customer cannot set the priority. Only the agent can upgrade or downgrade the priority after the ticket is assessed. The customers know through education that for 99% of their requests they will use this request type.

For Incidents (system failure affecting 5 or more users or a company wide failure) they have the ability to log a Critical or Major priority request type. My agents will again assess the ticket priority or the incident and if they deem it to be a Service Request instead of an incident they will change it. However, we have a label for this type of user error called 'picnic' (I am sure you know what it means), which is useful when it comes to reporting because we can easily see how many of these types of requests get logged and by whom, and then we can get back to the customer and offer more education on how to log requests properly. Over time the customers learn what is an incident versus a service request.

-Mike

Erin Collins_tcbbh0 · Accepted Answer

Hi @Lindsay Siurna ,

In my experience, it's still an Incident and a user/customer will fight to win the argument that it's an Incident and not some other type if issue. However, the value here will come in setting the resolution (or closure code, etc) which could be something like Training, which is an element of how you would identify multiples of the same kind of issue for continuous improvement opportunities - or items to flag for problem management!

I don't recommend going with a cancelled status or resolution or closure code, though, because it's a legitimate issue/query.

If the user has logged the ticket in JSD help center you might be able to do some initial triage there, but it sounds like it's a case where the user has already jumped through some level of hoops to the point where an agent is handling it. Good luck!

Erin