Should the Help Desk be the Place to Start IT Requests? Part 2

In Part 1, I questioned a fundamental assumption around IT services and how they are supported: that the Help Desk should be the place to start all IT requests. I used "request" in the most general form, meaning it could be reporting an incident, all the way to initiating a request for a new service. This assumption is practically a sacred cow in many IT shops. I even confessed to subscribing to this school of thought for a long time myself. The main point is that we've gone far away from the original point of using the Help Desk as SPOC (Single Point of Contact), which was to save money and improve the requester's experience. Am I the only IT manager that purposefully provided sub-par service when users contacted me directly instead of using the Help Desk? Based on my personal experiences as both an internal IT manager and an external service provider, I highly doubt I am alone. I've heard many stories of managers and senior engineers choosing to respond to direct requests for service by artificially delaying the response, and adding at the end something like, "You'll get faster responses if you call the Help Desk first."

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:

The requester knows the Help Desk is there, and yet they chose to go to you or someone outside the Help Desk anyway.

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:

1. 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.


2. Metrics should be based on whether or not the Help Desk is the preferred method of initiating IT requests.


3. 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.


4. IT frameworks and models such as ITIL, ISO/IEC 20000, COBIT, etc. provide excellent guidance once you've established the Help Desk as the go-to request initiation team; but while you're working to make that happen, be very careful where and how you use them in request processes. Some readers will have broader experience, but my experience has been that this is the very place where many ITIL "implementations" fail. Incident Management processes can be a square peg prematurely forced into a round hole. Once the hole is reshaped, those process changes work very well.


5. The SERVQUAL model, that I wrote about previously, provides an excellent way to guide your research. 

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.

IT Is No Longer a Corporate Support Service. Are You Ready?

If you are part of a corporate IT group, chances are you are struggling like I am with the concept that IT is a support service. It used to be taken for granted: our role was to be the implementers and fixers of technology. The implications being that things like budgets were looked at from a pure cost-centered approach. Provide the necessary technology at the lowest cost possible ... more akin to maintenance and facilities roles.

But corporate needs are shifting, often faster than corporate assumptions around the role of IT. Do you find yourself in this situation today? Corporate strategies and the objectives intended to carry out those strategies depend on technologies requiring more creativity and variability than ever before. Take social media as an example. As recently as five years ago, corporate on line presence was defined by a corporate controlled web site and corporate email. Some put in tools for real-time chat for sales and customer service; but the environment was still tightly controlled by the company. IT’s role was that of a relatively static entity to roll-out things. Even “dynamic” content was rolled out as a technology tool. Once programming and design were complete, it was essentially up to business users to make it work. IT was just there to fix it when something broke.

Compare that to online presence today. Social media that companies have little, if any, direct control over have dominated. Within a few years, it will saturate every nook and cranny of our corporate world. Traditional corporate content providers, like marketing, sales, and customer service, are ill prepared to handle the barrage of technological challenges in such an environment. If your company is anything like mine, they are now looking to IT to provide ongoing expertise in managing the corporate online identity. They key here is “ongoing”. The challenges of corporate online identity are constant; not needing an annual or quarterly technology refresh, but often requiring a daily, hourly, or even minute-by-minute refresh.

As old attitudes around the role of IT pervade, it’s easy for an IT department to say, “It’s not my problem. Sounds like a marketing problem to me. We can provide some consulting, but not much else.” But the business expects and NEEDS IT to become hands-on in managing online presence and identity.

Are they wrong? What are we prepared to do about it?

Do Users Prefer to Contact the Help Desk? Should They?

I've been thinking a lot lately about utilization of the Help Desk (Service Desk, whatever...), and how many of us in IT management constantly try to funnel all requests through the Help Desk. It was starting to bother me that most of us, myself included, spend an awful lot of effort telling end users not to go straight to other IT staff. I can't tell you how many times I've received a call or email from an end user, asking for help with a problem -- or answers to their questions -- and my response was to direct them to the Help Desk.

I recently realized how hypocritical this response is. A few years ago our Finance group made changes to the way we process corporate credit card transactions. Those of us outside Finance complained loudly to each other about how much harder the new system was for us. I was fond of telling anyone who would listen that I'd never endorse an IT project that made life easier for IT, but harder for everyone else. Ha! I understood service, and Finance obviously did not. It was probably within the same day that I told an end user, for the 80th time, that the Help Desk is the best place to go to start any IT inquiry. I love irony ... expect for when it convicts me.

A few days ago Aale Roos (Recommended Twitter follow) linked me to an article he wrote about the concept of Service Desk Market Share. Read up for a good discussion of some survey work he's done around the issue. His take is based more upon the idea of how many attempts a user makes before getting their problem resolved, and how many places other than the service desk a user goes to get help. My interests lie in the options users have in contacting different IT staff.

If an end user has a problem, question, or request to implement something, they have a myriad of choices of where to go to get help. Frequently, the choice is not the Help Desk. We know that self-help can be a great option. It empowers the user and lowers overall costs (assuming what they do actually helps, and they find the answer quickly). Within IT, however, our current attempts to FORCE use of the Help Desk is no better than Finance forcing an unwieldy reimbursement process on us. This is a simple truth:

If it doesn't improve the requester's experience, we shouldn't do it.

I don't advocate banishment of the help desk. Far from it. The Help Desk / Service Desk model allows for significant cost savings and professional management of business requests. Note that I say "allows for". All too often, the only benefit of the Help Desk model is to allow the staff that handles Level 2 and 3 support to spend more time on higher profile -- and therefor more business visible -- projects. Take a long, hard look at your support processes. Do they focus on improving the requester's experience, or are they really based on ensuring the techies don't get bothered by new requests? We've actually encouraged staff outside the Help Desk to turn away requests. The way to get users to access the Help Desk is for those in the other channels to make themselves look awful, right? Don't be embarrassed, we've all done it.

There. Doesn't it feel good to get that out in the open?

So, is your Help Desk the preferred choice when your customers need help or request something? Or are there alternatives, sanctioned or not, that your customers would rather use? Why?

In the next post, I'll look at some ways to start making the Help Desk the preferred choice, as well as how to determine when they shouldn't be the preferred choice. Please share your thoughts in the comments.