Branimir Valentic Once, when I started working for a multinational company, I needed my laptop to be installed. The first issue was that there was only kind of (meaning – with very narrow functionality) a Service Desk. Once I reached them, reported my request – the long wait started. Every time I asked about the status – no one knew what I was talking about. I had to explain from the beginning, which meant another loss of time (mine, as well as that of the people from the Service Desk).
Now, after many years in IT Service Management (ITSM), I wish that there had been a Service Request process in place. I would have opened a new Service Request ticket (or record), it would have entered the process, and someone would have been notified. Or, monitoring of the status, i.e., fulfillment would have been possible. No matter whether you implemented ITIL or ISO 20000, the fact is that you don’t need to reinvent the wheel. There is a lot of knowledge out there; you just need to take it and adapt it to your own requirements.
What are Service Requests?
Let’s clarify what a Service Request is. According to the ITIL, a Service Request is: “A formal request from a user for something to be provided.” This means that (if we compared it to more popular incidents) “everything is OK, no malfunctions, but I need something from you.” That “something” could be a new computer, information on how to set a delayed delivery of an email, password reset, etc.
ISO 20000 is more practical, so the Service Request definition in ISO 20000 is: “a request for information, advice, access to a service or a pre-approved change.” That helps us to get to the important relationship with Change Management; that is, standard (or pre-approved) changes are usually handled using Service Requests. For example, a password change is considered a standard change. So, Service Requests are an ideal way to fulfill that requirement. Information is documented, the task is assigned to the right person (usually – admin), and there is a record of performed activities.
There is one more difference between ITIL and ISO 20000. Service Requests, in ITIL, are handled by the Request Fulfillment process. ISO 20000 requires that Service Requests are fulfilled by the Incident and Service Request Management process. So, one process handles both incidents and Service Requests. In real life, ITSM tools usually have incidents and Service Request processes implemented, but if they don’t – then incidents are used with one incident category being, you guessed it: Service Requests.
About the purpose
Now we have clarified what Service Requests are. A Service Request record is a documented service request. So, the purpose of the Service Request record is:
- to enable end users to send requests for services, functionalities, HW, SW, general inquiries . . . etc.
- for the IT department to distinguish between incidents and Service Requests. Namely, incidents usually mean an interruption of a service. So, they need to be resolved ASAP. If you add some Service Requests to the list of incidents, without some distinction, the Service Desk staff will lose precious time while sorting and prioritizing Service Requests.
- to document all activities – that is valid for the whole lifecycle of the Service Request.
- to enable verification – some Service Requests need verification before they are fulfilled, like, e.g., a request for new equipment. If you have a process in place (Request Fulfillment or Incident and Service Request Management) and the appropriate tool – there is no place for error or misuse. When someone orders, for example, a new PC, the process will automatically send a Service Request to the employee’s supervisor.
The content
To be honest, it’s very relative to talk about the content of the Service Request, because it depends on a lot of parameters:
- Which services do you support?
- Which tool do you use?
- How complex is your organization?
- Which other processes do you have in place (particularly Service Asset and Configuration Management)?
But, based on my own experience, there are some elements that are usually part of the Service Request record in most of the implementations I’ve seen:
- General information – who opened the Service Request, or for whom the Service Request was opened.
- Timestamp – of the opening. Because you can have a Service Level Agreement (SLA) -related target to fulfill Service Requests.
- Specifics – a description of the requirements.
- Confirmation – some Service Requests need to be confirmed, i.e., approved before they are fulfilled. Take, for example, the ordering of a new PC. You can’t let end users decide to order new equipment; someone (usually their supervisor) has to approve that purchase.
- Priority – well, a Service Request can also have an impact (which is sometimes hard to elaborate) and urgency.
There is one thing that is important when we talk about the content of the Service Request record – a tool. If you are using an ITSM tool, then you depend on its functionality. Well, most of the tools are configurable, but in limited scope.
The use
It’s unpleasant to discuss usage of the Service Requests (and, therefore, Service Request records). Namely, Service Requests are used for many different topics. Once I witnessed a client who required that their consultancy services should be requested using – a Service Request. Why not, because in such way you know exactly who, what, when . . . When we talk about uses of Service Requests, sometimes I think that the imagination is the only limit.
Whatever the purpose and usage of the Service Requests, the Service Request record is your tool to have an overview of the activities and usage of resources related to Service Requests. In this way, you will be able to manage your own resources, manage your users’ requirements, be efficient, and keep bureaucracy to a minimum. That last argument is one of the most attractive one – no one likes bureaucracy, but everyone likes those who eliminate it. That could be you, couldn’t it?
Click here to see a free preview of a Service Request record template to see what such a record looks like.
