Any views expressed within media held on this service are those of the contributors, should not be taken as approved or endorsed by the University, and do not necessarily reflect the views of the University in respect of any particular issue.

ITIL Tattle

ITIL Tattle

Blog posts on ITIL and ITSM news and best practice from the ISG ITIL Team

When is an Incident not an Incident?

The word “Incident” has been used for many years at The University of Edinburgh. We used it in our original Call Management tool Remedy, then in CMS and when UniDesk our current ITSM tool launched, our individual tickets were called “Incidents”.

This never really sat well with the ITIL aware among us and so, in 2015 we made a change and our tickets became known as “Calls”

There was a bit of debate at the time around naming and we did consider using the word “Ticket”, but it was decided by the Edinburgh UniDesk Local Operator Group (LOG) that we would go with “Call”

But why were we ITIL-ites upset at the word “Incident”? Well the simple fact is that not all calls are incidents.

While 16% of all ISG calls handled are Incidents in the ITIL sense, 68% of them are Service Requests, with the remaining 16% being pretty evenly split between System Events and Requests for change

So, what’s the difference and does it matter? I started to talk about this in my previous blog post

Introducing Incident Management

and today I’ll expand on this.


Spot the difference

Spot the difference was always a favourite in puzzle books when I was a kid. But sometimes it was hard to see the difference as things seem quite similar. Thankfully ITIL describes the different call types in an easy to understand way.


  • Incident: An unplanned interruption to a service, or reduction in the quality of a service


  •      Service Request: A request from a user or a user’s authorised representative that initiates a service action which has been agreed as a normal part of service delivery


  •      System Event (Event) : Any change of state that has significance for the management of a service or other configuration item.


  •      Request for Change: A description of a proposed change used to initiate Change Management (Change Control in ITIL4)



You can see from these descriptions that the four types of call are quite distinct and therefore it doesn’t make sense to call them all Incidents.

“Call” is a far better description and has its own ITIL definition too:

Call: An interaction (e.g. a telephone call) with the service desk. A call could result in an incident or a service request being logged.

Now that we know the distinction between the different types of call, I’ll move on to give some real life examples of the different types.

Again, I touched on this in my previous blog post, but today I will expand using an entirely made up example.

Helping Andy Brennan

Andy Brennan, the head of a departmental security team contacts his Service Desk. Andy emails to say that he has a new member of staff starting in the security team and he would like them to be able to access the security team home drive. He also says that there is a computer available for the new staff member to use, but that it doesn’t seem to be connecting to the network. Finally, he mentions that the security team want to look at the possibility of using an out of hours chatbot service to deal with out of hour calls.

Its clear to see here that Andy has asked for 3 distinct things.

Access to the security team home drive.

This is a Service Request.

Why? This is a request from a user’s authorised representative that initiates a service action. The action being that the Service Desk will set the call type as “Service Request”, collect the relevant details relating to the user and the drive they need to access and will then pass that request on to the relevant second line team and ask them to grant the permissions.

Computer not connecting to the network

This is an Incident.

Why? This is an unplanned interruption to a service. The Service Desk should separate this into a fresh call and ensure the call status is set to “Incident” then gather some extra details from Andy about the network fault. They may be able to resolve the Incident at first line, failing that they can escalate it to second line for further diagnosis.

Use of out of hours chatbots

This is a Request for Change

Why? This is a proposed change and will be used to initiate Change Management. We don’t currently offer a chatbot service, so the Service Desk should create a third call for Andy and make the call type “Request for Change”. As this request will require some discussion and further consideration its likely the call will be passed to our second line Business Relationship Management team so that we can explore Andy’s requirements.

But what about System events

It’s unlikely (but not impossible) that Andy will raise a System Event. Here at The University of Edinburgh our primary use of the “System Event” call type is to record and review system log files from the various servers, databases and infrastructure we have here. The system event records are often suppressed from general view in UniDesk and only reviewed when an outcome changes from that which is normally expected.

You can see here that we do have very distinct types of call and that there are clear differences. In my next blog post I will explain the other considerations that need to be made when handling different types of calls and why ITIL makes all of this gel together to handle the call lifecycle process.

Leave a reply


Report this page

To report inappropriate content on this page, please use the form below. Upon receiving your report, we will be in touch as per the Take Down Policy of the service.

Please note that personal data collected through this form is used and stored for the purposes of processing this report and communication with you.

If you are unable to report a concern about content via this form please contact the Service Owner.

Please enter an email address you wish to be contacted on. Please describe the unacceptable content in sufficient detail to allow us to locate it, and why you consider it to be unacceptable.
By submitting this report, you accept that it is accurate and that fraudulent or nuisance complaints may result in action by the University.