May I Take Your Order? How to Free Up Your Service Desk by Adding Service Requests to its Menu

"Good morning, this is Jane Doe of the XYZ Service Desk. How may I help you?"
Countless Service Desks across the nation and around the world repeat a similar greeting every minute of every day, and then they begin a scripted routine of logging the Incident, categorizing it, diagnosing it, restoring service, and closing the Incident. Many Service Desks streamline at least part of this routine by creating self-service sites that allow Users to enter Incidents themselves and perhaps access a knowledgebase to do some self-diagnosis and recovery.

What if the Incident is not an Incident?

Consider an imaginary call to the Service Desk. A user reports that his jobs print to the wrong printer. Upon investigation, the Service Desk determines that a recent organizational change moved the printer normally used by the caller to another part of the building. The user's office did not move, and he must walk to the printer's new site to collect his print jobs. The Service Desk notifies its second-level support team, who activates the user on a printer convenient to his existing location.

Although the Service Desk may have treated the above scenario as an Incident, no part of the infrastructure actually failed. It was, plain and simple, a Service Request. It can be argued that a more robust plan for the office move would have included this Request in its preparation checklist, but it always was a Service Request.

ITIL has long described the Service Desk as a Single Point of Contact between IT and the User. As one of the key functions in the Service Operation phase, the Service Desk extends its service approach to encompass Service Requests as well.

Building Request Models.

How does adding more responsibilities to the Service Desk free up staff? The answer is really quite simple, and lies in the adoption of the Request Fulfillment process. Unlike Requests for Change (RFCs), which require assessments along with possible infrastructure changes and requisite funding, Service Requests address small changes. Service Requests are typically low risk, low cost, and frequently occur.

The difference is that Incidents are largely unplanned events, while Service Requests can - and should – be planned in advance with the aid of a Request Model.

Fig. 1 - Service Operation Process Model

The beauty of a Request Model is that it systematizes requests that are performed frequently, shifting the emphasis of your valuable Service Desk staff from a "one-off" Incident Management mode to an efficient Request Fulfillment management mode. This results in a more efficient Service Desk because it now has a 'script' to follow for Requests as well as Incidents.

Follow these steps to build a Request Model.

1. Identify the Request. Typical request types are reconfiguring printer assignments, adding user workstations, user moves, adding printers, etc. Don't forget changes in access via the Access Management process!
2. Identify Responsibilities. You will need to identify who has the responsibility for authorizing the fulfillment of a request. This also includes any funding for the request. For example, a department manager may be authorized to add a new employee, and that authorization can also ‘flow through’ to the Request Fulfillment model to provision the workstation for the new employee. Similarly, a department manager may need to authorize an employee request to purchase a new printer.
3. Identify the Steps to Fulfill the Request. Frequently many different IT and business departments participate in fulfilling a request. For example, adding a new printer may require participation by Purchasing (place order with vendor), Network Support (add and configure network connection), Desktop Support (configure printer and User’s workstation), Application Support (configure printer into the Application), Maintenance Vendor (add printer to maintenance contract), Supply Department (stock appropriate printer cartridges), Training (if the printer is a new model), etc. A workflow system, such as used by many Service Desks, is an ideal application to document and track these steps.
4. Identify Timescales to Fulfill the Request. Identify how long each step should take and what notice the Service Desk will receive upon completion of the step - or if the step cannot be fulfilled as scheduled.
5. Identify Escalation Procedures. Although this is a Service Request and not an Incident, there is still the possibility that a Request will not proceed as planned. Escalation procedures establish a channel of communication for Service Requests that fall outside of the normal workflow.
6. Establish Documentation Requirements. This includes adding changes to the Configuration Management System, submitting invoices for payment, adding hardware to maintenance contracts, etc.
7. Validate and Close the Request. As with an Incident, it is necessary to include steps to validate the fulfillment of the Request and to formally close it in the Request Fulfillment system.

Summary

Building Request Models helps make your Service Desk more efficient in two ways. First, it establishes a standard set of steps and procedures for frequently occurring standard requests. Second, it establishes a procedure to seamlessly deal with an Incident that really turns out to be a Service Request. Finally, the efficient and effective processing of Service Requests can provide yet another feather in the Service Desk’s User Satisfaction hat.