OK, who is kidding whom here? You cannot build a help desk users will love. But you can build a help desk that users will tolerate. And you can build a help desk that scales. You can also build a help desk that follows a repeatable process.

The Help Desk Satisfaction Paradox

A customer approached me and asked if we could help them build a help desk function that was better than what they have now. Of course, we can help! (We are consultants; we are trained to always say “yes!”)

This customer has a help desk arrangement we see quite often. They have a few IT staff that handle help desk requests (among many other duties). The bulk of help desk support is outsourced to a support provider.

I started by looking at help desk statistics for this customer. The numbers were not good. When asked to rate their satisfaction with the help desk function, most users rated it in the “Dissatisfied” or “Very Dissatisfied” range.

But if I asked users about their help desk experience, they would say something like this. “The help desk is not very responsive. But not Bernie! Bernie always gets back to me right away.”

What is going on here?

It seems there are two help desk processes here.

• Submit a ticket, wait for the support engineer to call you, explain your problem, wait for a solution.
• Call Bernie, tell him your problem, wait while he fixes the problem before you hang up the phone.

(I feel like “hang up the phone” is one of those “tell someone how old you are by repeating a once-common phrase” things.)

Understand Why There Are Two Help Desk Processes

Most IT folks will tell you that you want to have just one help desk process. It is akin to the John Madden saying, “when you have two starting quarterbacks, you have no starting quarterback”. If you want to build a help desk that works, start with a single support process.

But before you move to one process, understand why there are two support processes now. Why do users follow one or the other process? Here are some possible reasons.

• Users prefer a personal touch. Everyone knows Bernie!
• Sometimes a user needs a solution now. I have a presentation in fifteen minutes and my laptop is not connecting to my monitor! I cannot wait three days for a help desk person to call me.
• Users hate submitting tickets. “It’s broken! I don’t know why!” Users are already frustrated. Opening a ticket does not feel like it is helping get to a resolution.
• The help desk works support tickets based on who is available at that moment. As a result, users find that they must explain their problem again to each new support desk person they talk to.
• Maybe there is a sense of entitlement in play. “Hey, I am a big shot around here! I deserve some personalized service!”
• Bernie doesn’t have the heart to tell people to submit a ticket first.

Balance Scalability, Repeatability and Responsiveness

You want a ticketing system. Even if users generate a low number of help desk tickets per month, it is still a good idea. Why? Because a ticketing system will help you uncover trends. Maybe a lot of users are submitting tickets on how to change their Zoom background. That might indicate some training is in order.

That said, a help desk function that is efficient but unresponsive does not work. You want users to feel like IT is a partner helping them succeed at their work. You do not want users thinking of IT like Nurse Ratched (here is a link for the younger demographic).

Build a Help Desk That Works for Everyone

Here are my thoughts on actions you can take to build a help desk function that works for users and IT.

• Communicate with users. Explain why IT needs a repeatable help desk process. Ask for their help in getting there. Show users that they can help build a help desk that works for everyone.
• Explain the process for submitting a ticket. Make it as simple as possible.
• Put your IT help desk people in place as the first line of support. Let users see and talk to Bernie first. Let Bernie open the ticket while he is talking with the user.
• Empower Bernie to make the decision whether to hand the ticket off to the outsourced help desk. Encourage Bernie to hand off the ticket when he can and limit the tickets he works on to those emergency situations. Remind Bernie that help desk is not the only responsibility he has.
• Have Bernie follow up with the user to close the ticket. Bernie can make sure the user is happy and the problem is solved.
• Every so often, “shadow” a ticket sent to the outsourced help desk. What is the interaction with the user? Is the help desk showing some empathy? Is the help desk meeting its support commitments? Take corrective action when you need to do that.
• Ask users if they are seeing improvement. Check the help desk metrics to see if they support what you are hearing.

The process to build a help desk that works is not fast. Nor is it easy. But it is possible. Now go and do!