Considering Calls
In my last post I spoke about the different types of calls that we see here at the University of Edinburgh and this post is an expansion on the topic, where I’ll explain more about the considerations that we need to make when handling different types of calls and what makes each call type unique.
As a reminder we have four call types in UniDesk our Service Management tool.
-
- 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, sometimes used to initiate Change Management (Change Control in ITIL4)
Most of you will be familiar with Incidents and Service Requests and less familiar with Requests for Change and System Events, but all of these call types are used at the University of Edinburgh and all require a slightly different approach.
Service Requests
Service Requests make up 68% of all Information Services calls in UniDesk. Every Service Request should follow a process which will usually be well defined and be a normal part of the service a Team delivers.
The fulfillment of Service Requests, otherwise known as Request Fulfillment has several objectives:
- To provide a channel for callers to request and receive standard services
- To provide information to callers about the availability of services and the procedure for obtaining them
- To source and deliver the components of requested standard services (e.g. Software Licences and Software)
- To assist with general information, complaints or comments.
At the University of Edinburgh many of our calls come in through the ISG Helpline Services, our central support service. The Service Requests that the Helplines see range from a new staff member requesting their Computer login and password, through a student requesting extra storage space for their Research project on the Datastore, to things like requests for software licences.
The Helpline have defined processes for fulfilling these requests, they’re the sort of thing that will come to Helpline many times a day and things which they can process at First Line without requiring any additional interaction with other teams, or seeing the caller face to face. Most Service Requests will be fulfilled in a very short timespan unless there is a need to await further authorization or confirmation from the caller that they now have what they need.
This results in callers being able to quickly receive the service they require and, if process is well understood it can often allow request fulfillment to be centralized, thus avoiding duplication of effort and saving on staff resource.
Service Requests will usually remain as first line calls for their entire lifecycle and will often be of a less urgent nature.
Incidents
Incidents are unplanned interruptions to service, or reduction in the quality of a service. So, if you go to print something and the printer has an error code on it, this is an incident. Likewise if you try to login to your computer and get a network error, this is also an incident.
Incidents will generally be more disruptive than service requests and will take varied amounts of time to resolve.
The goal of Incident Management is to restore normal service as quickly as possible and minimize the disruption to the caller.
Incidents will usually come through a Service Desk, however technical staff will often create an Incident if they notice something untoward on a server or other Infrastructure component.
Incidents will often have to pass through a few different teams before they are resolved. Any incident reported by a caller will always start and end with a Service Desk. Some technical staff may do some proactive Incident Management and create a second line Incident. this means that Incidents will sometimes be first line only (if logged and resolved by a Service Desk), second line only (if logged and resolved by a technical team) or both (if logged by a Service Desk and resolved by a technical team)
A collection of Incidents all for the same issue is known in ITIL terms as a Major Incident and you can read more about Major Incidents in Robert’s previous post.
Incidents often require a more urgent solution than Service Requests or Requests for change.
Request for Change
A Request for Change (or RFC) in ITIL terms is a formal proposal for a Change to be made, however in UniDesk we use the call type of Request for Change as a way of capturing informal change requests that haven’t come in through the usual Change Management or Change Control process. The Request for Change call type is used to capture calls where a change is required that isn’t routine, or wasn’t anticipated.
This could be a request to change to the version of MS Office that we use here at the University, a request to change to the opening hours of a user facing service like the IT Support Desk, or a request to change the physical network wiring in one of our DataCentres. A Request for Change will often be changed in to a formal proposal for change and carry on to be processed through our Change Management process.
A Request for Change will generally happen for one of the following reasons:
- A change is required to resolve an Incident or Problem Report
- A caller has expressed dissatisfaction with an aspect of the current service
- The University wants to introduce a new service
- One of our existing services needs to be upgraded
- Legislative changes such as GDPR.
Here at the University of Edinburgh a Request for Change may start life as an Incident or Service Request, or as a Request for Change. If the service owner reviews the Request and feels it is a valid request requiring further action they will create a Change record in UniDesk.
Within Change Management some projects will create Requests for Change as part of a project lifecycle and these request types will usually result in a change record.
We have a number of Change Advisory Boards (CABs) here in ISG and these boards will demand that a change record has certain information in it, including things like test and rollback plans. CABs convene regularly to discuss proposed changes and communicate the decision of their CAB to the Change requester. You can read more about CABs and our GoCAB in Matt’s post here.
System Events (Events)
The final type of call we use is known as a System Event. We do see System Events here at the University and some technical people will see many system events every day, some in UniDesk and others directly in the software or service that they are accountable for.
System events are usually alerts or notifications created by the hardware, software or infrastructure (network, power, telephony) and often generated by a monitoring tool. Any System Events in UniDesk will usually be created by a non human input, however a person may choose to copy their log files or alerts from another service in to UniDesk for further processing.
Some events will be for notification only (a log file showing that a backup of a server completed successfully is an example of this) However many System Events will result in the creation of an Incident or even in a request for change.
Service Desks and first line teams are unlikely to see many System Events, however some second line teams will see far more System Events than they would like at times!
Its vital to monitor System Events so that our services remain in the state that they need to be.
The Fab Four
So there we have it. The Fab Four. No, not the ITIL team, but Four types of call and four sets of considerations all of which Come Together as a group of guidelines that hopefully help you see how ITIL processes can add value to call management here at the University of Edinburgh and help you on the Long and Winding Road to Service Management success!
And if you’re still confused then all you need to do is ask for Help! from the ITIL Team and We Can Work it Out together!
(With apologies for the bad Beatles puns, James will be back next week with a much better class of pun!)
(Lisa McDonald. Dec2017)
Recent comments