The Importance of Help Desk Process and Evaluation

Recently I had an experience with a transitioned help desk that really showed me how a lack of thorough processes and a solid knowledge management system can really sink your help desk right out of the gate.

This made me reflect on how detailed processes play such a big part to the success of a service desk. In this post, I will detail how I approach process analysis and/or creation. For this topic, I will not go in to detail about knowledge management, as we will cover this later.

To determine the strength of your processes - whether transitioning, creating, or analyzing an existing desk you must look at the pain points you are suffering. Pain points come by way of:

• Nasty emails from your tower/business peers such as a manager in another department wondering why their subordinates are sitting idle "waiting on IT to fix things".
  
• They may come from your customers in the form of negative surveys or continuous call backs wanting ticket updates.
  
• Perhaps your technicians continuously complain that they don't know where to send a ticket or they always have "those strange, one-offs" for which no support is known.
  
• Even worse - tickets are being mis-routed to incorrect groups en mass causing frustrations, flare ups, and finger pointing in your weekly status meetings.

If you find yourself
sitting in front of email all day...
being tapped on the shoulder constantly....
hiding in the bathroom to take breaks....
explaining yourself to your boss more than envisioning the future of your desk... then you probably have weak or inadequate processes.

So, where are you at? Do you have processes at all? No, I mean documented processes. If sharing the process means you have to tell me what it is, then it's not really a process. Well, I suppose you could call it a process, but it's a process prone to change, error, miscommunication, you might forget it, or heaven forbid it "walks" out the door. That reminds me of a story about this guy Vinnie who was my team lead when I was a support technician.

Vinnie had the life....he didn't have to be on the phones, he only had to answer our "next-level" questions if they weren't in the knowledge base. But he mostly played around with little trinket puzzles and surfed video game blogs. Vinnie hoarded all the information he could find and locked it inside his head. He wouldn't share or document things. Naturally, he was the most valuable player on the team. He had sponged everything. The desk was very unstable after he left.

My point is a process should be clear, hold accountable those who create, change, and implement the process, and provide clear direction to anyone who should read the process.

So, analyze where you are currently and get a good starting point. Create a focus group consisting of one of your brightest technicians...not necessarily the most technical. You want to see what's broken with your internal processes and this will be very different than just something your run of the mill technical person might be good at. If you don't have someone to help then perhaps you are the best to pick apart your process.

First, use the Input | Process | Output methodology to build a "road map" of your current processes. I've included a basic example above. Start at a high level such as the example above and begin "peeling the onion". You will find yourself creating more process boxes, decision trees, and you will probably find some questions. If you get to a dead-end or if questions start to arise then "light bulbs" might begin going off. That's okay. Make notes, but don't try to create solutions yet. You probably don't have all the correct information to complete the exercise in it's final state. We're just looking at the current state process.

Complete this exercise and we'll discuss more on the analysis and solutioning of the process problems in my next article.