It seems innocent enough, doesn't it? I still responded to the user's request, and I let them know they received a delayed response because they went through me instead of the Help Desk. We rationalize that behavior with thoughts like, "They were lucky I was available as quickly as I was this time. What happens next time when I'm away at a conference or something else equally important (Something obviously more important than a user's service request)?" The Help Desk exists to take in these requests. I have a lot of other work to do.
The rationalizations seem to make a lot of sense, until you come to this other realization:
To the requester, there is value in using options other than the Help Desk. IT's response for far too long has been to force users to go to the Help Desk, for their own good. At the same time, we devalue the Help Desk staff by making sure they are the lowest paid, least trained, lowest rung on the IT food chain. We assume it's a job anyone in IT could do. And then we're shocked that everyone hates the IT department? Seriously?
We need to change this approach, and we need to do it NOW. Here are some tips for changing how you position your Help Desk:
- The Help Desk's purpose should be clearly defined to include professional management of IT requests, open to close and verification, and making the Help Desk the preferred option for initiating requests.
- Metrics should be based on whether or not the Help Desk is the preferred method of initiating IT requests.
- Accept the fact that some request scenarios may well be best served outside the Help Desk. Do some research and figure out what kinds of requests get initiated outside the Help Desk most frequently. Before you start figuring out how to get those requests to go through the Help Desk, ask yourself a few questions:
- What would it take to make the Help Desk the preferred option for this type of request?
- Will that result in a better experience for the requester?
- Is it worth the cost and time to make the necessary changes?
- If the answer to the last two questions is anything but an emphatic "Yes", consider leaving things as they are.
Per the model, the core measurement of service quality is the gap between the customer/consumer/user's expected service, and the service they perceive to have received (My Gap 7, SERVQUAL's Gap 5). How much of the efforts around ITIL, ISO20000, COBIT, etc. are focused on that gap? Aren't most of our efforts around Service Strategy, Design, and Transition? At best, those efforts have an indirect impact on the quality of service provided. I'm not suggesting that we abandon efforts around Strategy, Design, and Transition. Far from it. Rather, I recommend placing those efforts in their proper context -- that of supporting the goal of reaching and exceeding customer expectations.
So we can safely assume that forcing users to start all requests with the Help Desk does not meet, much less exceed, our users' expectations. As always, measure the gap to validate.
After validating the existence of a gap, and determining that the size of the gap justifies further efforts, we see another common problem. When it comes to the support side of Service Delivery, we frequently focus efforts on Incident Management or Problem Management. But look at the model again. The service delivered is only one of at least six different inputs that affect either side of the service quality gap. Assuming your Incident Management is at least somewhat matured from an ITIL perspective, that means we are likely putting our efforts into the one input we are most likely doing fairly well. The common excuse is that the ITIL-defined processes are the only things we have immediate control over. We're essentially saying, "We do our part in the quality equation just fine, so it must be the users' fault that they go around the Help Desk." This is classic "Inside-out" thinking that, as suggested by Ian Clayton, threatens the survival of ITSM programs. That's not to say that inside-out thinking is always bad; it's just limited in what it can accomplish. Famed quality guru W. Edwards Deming once stated that you can have zero defects AND zero customers.
There are at least 5 other inputs into the expectations - perceptions gap:
- IT Communications impact users' perceptions of service
- IT Communications also impact users' expectations of service
- IT's Service Design and Service Transition efforts impact expectations
- The user's own experiences and history impact their expectations
- The user's business unit, with their own goals, strategies, and tactics, impact the user's expectations
ITIL and other frameworks only help us with 2 of the 6 direct inputs into the expectations - perceptions gap. By all means, look at your Incident, Problem, Transition, etc. management processes. Making those better will help close the gap. By showing us the specific inputs to address, the SERVQUAL model can help make managing the rest of the gap more pragmatic.
If your Help Desk is not the place your users want to initiate requests, don't give up. You have the tools to both exceed user expectations and be cost/process effective.