Service Requests - theory vs. reality

[rpmason]

In theory ITIL Service Requests are basically any request for service.

I've read the discussion from 2005 regarding Service Requests and came away with some good fodder. However, I'd like to ask a simple question.

In reality, which service requests are really not practical to run through the Service Desk?

Our draft IM plan currently lists the following examples.
Requests for information
Procurement requests
Batch job requests for a specific purpose
Service extension requests
Password resets
Operational queries and processing
Change Requests

Requests for information and password resets and such are obvious service requests - as are requests for standard changes. But I'm a bit leery of running procurement requests and such through our Service Desk.

Background:
I'm in a data center. Our customers talk to their end users; we talk to our customers' programmers, application administrators, project managers, etc.

Our customers aren't going to ask, "Can we add a couple more gigs of storage to our application?" because if they needed it, our admins would work out the details and put in the RFC. But our customers have said, "We're streaming live video on our website between 9-10 Monday morning, can the NOC please monitor the webservers more closely than usual."

Thanks! --rpmason

[asrilrm]

Hi,

To your list:
- Request for Information: Service Desk
- Procurement requests: Procurement Team internally; SLM or CRM externally
- Batch job requests: Service Desk
- Service extension requests: SLM
- Password resets: Service Desk
- Operational queries and processing: Service Desk
- Change requests: Change Management Team internally; SLM or CRM externally

But those are what apply in my company. Might not be the same for others.

Cheers,
Asril

[Diarmid]

Hi rpmason,

in reality all of your list is appropriate to go through the service desk - or not depending on how you operate.

First benefit: you have one central point at which to track progress against commitment. Therefore you have a complete picture in one place of what any customer is waiting for or might be agitated about.

Second benefit: having a consistent central record of all requests (and their outcomes) that come from your users and customers, helps with the analysis, e.g., for service improvement or service re-alignment programs.

The way to make it work is by passing the request promptly to the right group (e.g. procurement, server admin.) and let them manage and perform the process. They can close the request on your service desk when it has been delivered.

If you have customers and users talking directly to different support and service units it is much more difficult to manage the overall customer relationships. The danger areas include customer authority, prioritizing of work (resource management), duplication, inconsistent delivery. Rigorous procedures are needed to minimize these risks.
_________________
"Method goes far to prevent trouble in business: for it makes the task easy, hinders confusion, saves abundance of time, and instructs those that have business depending, both what to do and what to hope."
William Penn 1644-1718