Last updated 17/06/2020
"Incident" has been utilized for a long time at The University of Edinburgh. They utilized it in their unique Call Management apparatus Remedy, at that point in CMS, and when their current ITSM device UniDesk propelled, the individual tickets were classified "Incidents".
This never truly agreed with the ITIL mindful among them thus, in 2015 they rolled out an improvement and the tickets got known as "Calls"
There was a touch of discussion at the time around naming and they considered utilizing "Ticket", yet it was chosen by the Edinburgh UniDesk Local Operator Group (LOG) that they would go with "Call"
In any case, for what reason were ITIL-sites steamed at "Incidents"? All things considered, the straightforward reality is that not all calls are episodes.
While 16% of all ISG calls took care of are Incidents in the ITIL sense, 68% of them are Service Requests, with the staying 16% being pretty equally part between System Events and Requests for change.
All in all, what's the distinction, and does it make a difference? Today We'll clarify this.
Spot the difference was consistently the most loved in puzzle books when we were kids. Be that as it may, in some cases it was difficult to consider them to be as things appear to be very comparable. Fortunately, ITIL portrays the distinctive call types in a straightforward manner.
It is clear from these descriptions that the four types of calls are quite different. Hence, tagging them all as it doesn’t make sense to call them all Incidents.
“Call” is a far better elaboration and has its own ITIL definition too:
Call: Cooperation (for example a phobe call) with the service desk. A call could bring about an incident or a service request being logged.
Now that we know the difference between the different types of calls, we will move on to portray a real-life scenarios of the different types.
Suppose Mr. X is the head of a departmental security team. He contacts his Service Desk. Mr. X drops a mail to state that he has another individual from staff beginning in the security group and he might want them to have the option to get to the security group home drive. He additionally says that there is a PC accessible for the new staff part to utilize, yet that it doesn't appear to associate the system. At last, he makes reference to that the security group needs to take a gander at the chance of utilizing an out of hours chatbot administration to manage out of hour calls.
It’s reasonable to see here that Mr. X has requested 3 particular things.
This is a Service Request.
Why? This is a solicitation from a client's approved agent that starts a service action. The activity is that the Service Desk will tag the call type as "Service Request", gather the applicable subtleties identifying with the client, and the drive they have to get to and will at that point give that solicitation to the important second-line group and request that they award the consents.
This is an Incident.
Why so? This is a spontaneous interference to support. The Service Desk should isolate this into a new call and guarantee the call status is set to "Incident" at that point. After assembling some additional subtleties from Mr. X about the system issue. They might have the option to determine the Incident from the start line, bombing that they can heighten it to the second-line for additional finding.
This one clearly is a Request for Change
Why you may ask? This is a proposed change and will be utilized to start Change Management. The service providers don't as of now offer a chatbot administration, so the Service Desk ought to make a third call for Mr. X and decide type "Request for Change". As this solicitation will require some conversation and further thought, it's reasonable the call will be passed to the second-line Business Relationship Management group with the goal of investigating Mr. X's necessities.
It's far-fetched (however not impossible) that Mr. X will raise a System Event. At The University of Edinburgh, the ITIL team's essential utilization of the "System Event" call type is to record and audit system log documents from the different servers, databases, and foundation we have here. The system event records are frequently stifled from general view in UniDesk and possibly explored when a result changes from that which is regularly anticipated.
You can see that they do have extremely particular sorts of calls and that there are clear contrasts. We will clarify different contemplations that should be made when dealing with various kinds of calls and why ITIL makes the entirety of this gel together to deal with the call lifecycle process. For that, stay tuned to our blogs!
NovelVista Learning Solutions is a professionally managed training organization with specialization in certification courses. The core management team consists of highly qualified professionals with vast industry experience. NovelVista is an Accredited Training Organization (ATO) to conduct all levels of ITIL Courses. We also conduct training on DevOps, AWS Solution Architect associate, Prince2, MSP, CSM, Cloud Computing, Apache Hadoop, Six Sigma, ISO 20000/27000 & Agile Methodologies.
* Your personal details are for internal use only and will remain confidential.
|AWS Solution Architect Associates|
|PRINCE2® Foundation & Practitioner|
|ITIL® 4 Foundation|
|DevOps Foundation By DOI|
|ITIL® 4 Managing Professional Bridge Course|
|Certified DevOps Developer|
|DevOps Practitioner + Agile Scrum Master|
|Certified Digital Transformation Officer|
|Certified DevOps Engineer|
|ISO Lead Auditor Certification|
|Microsoft Azure Administrator AZ-104|
|Certified Full Stack Data Scientist|