ITIL Best Practice-Converting Request to Incidents

Gemma4
Mega Sage

From an ITIL Standpoint has anyone converted a Request to an Incident successfully? We received a requirement to allow the Service Desk to convert Hardware Requests to Incidents and we are trying to determine if this is a best practice to do based on ITIL standards or what would be best?  Thank you in advance for any feedback or suggestions you may have. 

Gemma

1 ACCEPTED SOLUTION

Dan O Connor
ServiceNow Employee
ServiceNow Employee

There are in my opinion two methods/avenues to approach this in the platform. 

1) Requesting user log an Incident. 

This simply involves the agent closing the Request as invalid and directing the user to log an incident. Some teams or departments will look to do this as a way of training/education for staff to raise requests correctly, or educating where these types of requests go. 

Personally it's not a favorite of mine, as I think it's nicer for Help/Service desks to be able to either convert these requests or put them into the correct spots, and just drop a note to the requester. But have seen some scenarios where teams have had to take these hardlines with staff. 

2) Convert a Request to Incident.

There is unfortunately (to my knowledge) no OOTB method to do this yet(You can raise Requests from incidents) so you may need to look into some configuration for this. I've seen/created some nice UI actions that agents can convert Requests to Incidents in a single press. This is obviously if you are looking for a platform method to convert, as opposed to the agent just manually recreating for the user.

 

At a high level though your use case is pretty common, and it's definitely something plenty of people do. I don't think there is a definitive ITIL process to cover this, it's somewhat depending on your environment and you will know your staff best 🙂 

View solution in original post

5 REPLIES 5

Community Alums
Not applicable

Hello Gemma4,

first let me be a wise trainer guy: ITIL is no standard but best practice (that means, it tells you what to consider instead of how to do it)."

 

In the ITIL framework Incidents are unplanned interruptions of services and Requests are everything else (requests for information, access a service, get harware or software, ...).

Ideally Requests for specific services (install, modify, delete) should be preplanned together with steps for approval/fulfilment (request model) when defining the service (e.g. expanding a mailbox).

 

Thus in the ITIL world there is no need to convert one into another.

 

However, in reality, the user opens an incident and 1st level finds out, that user is just not entitled to use it in the first place. therefore no incident (no unplanned interruption). question back to the user: "do you want that service, then please request it". So moving from one ticket type to the other is a usual usecase in companies.

 

Fundamental difference between Requests and Incidents (in ITIL and in reality):

  • Incidents do not need approvals. Service was sold and is not working properly. Thus it needs to be repaired. No question about it.
  • Requests can be approved (but do not have to).

 

What irritates me in your first post: why should a hardware request be logged as an incident?

Hardware is broken and needs to be fixed -> Incident

Harware requested as new/modified -> Request

 

Summary: the initial assessment of ticket creator (end user) is sometimes wrong so the issue ends up in the wrong queue.

Interactions (transformed to incidents or requests by agents) is one method to solve that in ServiceNow

Cancel ticket and reopen in other queue (probably with copy-and-paste-help from the tool) by agent is the other way to solve it.

In terms of consistency of ticket numbers and transparency to end user and reporting I like the Interaction (slightly) more.