Tuesday, July 21, 2015

THE HELPDESK

What is it?

In its simplest form, a helpdesk is a group of people assigned to assist customers in solving their problems.  There are many different types of helpdesks and they are called by a variety of different names depending on the function that they serve, however the main point to make clear is that their purpose is to resolve a specific issue for a paying customer.

Types of Help Desks

At its simplest you could break down Help Desks into two main types. There are definitely sub categorizations within each type and quite often they are called different things, but from an end users point of view there are really only two different types:
  • Contact/Customer Service - this type of helpdesk is generally more administrative in function and scope. They would provide customers with account information and perhaps act in a sales capacity with regards to new services and other offerings that might suit the clients needs.
  • Support & Technical Operations - break/fix or tech support or network operations or the NOC. The names are many and varied for this type of team, but their primary purpose is to resolve a specific incident or problem and restore the customers service in as timely a manner as possible. Frequently this team is considered 2nd level and is senior to the Customer Service team but this is not always the case.

Customer Service Helpdesks

 Often referred to as a Contact Centre, these types of teams are more administrative in function and responsibility.  They are frequently called upon to provide customers with account information or deal with billing concerns.  While they may arrange visits with or escalate issues to the technical team, these individuals do not generally have the skills in-house to troubleshoot and resolve customer "problems".
Quite often you will find that companies outsource this function to other companies and even other countries as it is more of a generic job then Technical and Operational Support.  However in recent years this trend has been reversing as regardless of the cost, companies are striving to present customers with a more intelligent and higher quality of service.  Please note, outsourcing is not inherently bad by any means - if done properly, customers will receive a faster reponse time and all the information that they require to resolve their account issue.  However - to provide this level of support, companies need to provide the outsourcer with a significant level of access into their own internal systems and customer records.  In addition to this, the training that the outsourcer provides to their own staff is generally at a lower level than that provided internally - hence the quality of the answers provided are generally not at the same level.
In addition to the quality issues mentioned above, companies are actually using the fact that they provide service "in house" as a selling point, hoping in some cases to garner more customers simply based on "national pride".

Incident & Problem Management

As mentioned previously, these teams are known by a variety of different names, but probably the most accurate name for them is the Service Desk. Based on the ITIL (Information Technology Infrastructure Library) framework, the Service Desk is a component of the Incident Management team and they are responsible for resolving Incident's and escalating Problems.

What is an Incident?

Simply put, an Incident is anything related to a customer contact (Incidents are also reported by automatic means via monitoring toolsand I will discuss those types of incidents in greater depth in later posts).
Please note - Incidents are not restricted to technical teams, but can be something that a Customer Service team deals with also.
Incidents related to customers can be anything really – Information requests, Account Updates, Issue reporting are all examples of Incidents.
Incidents can also be reported through a variety of different methods – this could include the phone (probably the most common), email (a close 2nd) and even chat. As mentioned previously, automated monitoring tools can also generate incidents.
All of these different Incidents coming from/through different sources would get routed to your Incident Management tool. For smaller teams this could be something as simple as a spreadsheet but in larger organizations either in-house customer built applications or enterprise level tools prevail.

Incident Management (in a nutshell)

Your helpdesk is responsible for reviewing the information in each of these incidents and checking if there is an appropriate solution already available to the customer.
For those instances for example where the customer wishes to update their Account Information, the helpdesk would look at the Incident, obtain the correct new information (& assuming that all appropriate security questions had been reviewed) log into the customers account and update the information. Once the information had been updated, they would inform the customer and then close the Incident. This is probably one of the simpler examples of an Incident from start to finish.
If the customer is reporting a problem or an issue, the Helpdesk staff are responsible for updating the Incident with all the relevant details as supplied by the customer. If the customers issue matches a known fix they are able to inform or supply that fix to the customer, however, if that is not the case they would need to escalate the issue to the Problem Management team. The simplest way to think of the Incident Management (Helpdesk/Tier1) team and the issues they resolve is that if a "band-aid" exists they can apply it. If more drastic attention is required they will need to call the Doctor!

Problem Management

Problem Management is where the interesting work really happens. Incident Management due to its repetitive nature can get tedious and is definitely a drain on the more skilled staff in your organization ... if you have people like that, think about moving them into Problem Management if you have such a team or create one if you don't!
Problem Management is more in-depth. It's where more often than not a single Problem is the cause of multiple Incident's from multiple customers ... as such you want your best people at this level. Generally you would consider this Tier 2 or Tier 3 from an escalation and staffing perspective and dependent on your product or service you would have some very technically oriented people there.
Their goal is not to just provide a band-aid, but rather to find out why the problem happened in the first place and fix it. Ideally they should be looking at ways to fix it in such a way as to ensure that it doesn't happen again!!

KPI's & Metrics

Regardless of the type of Help Desk you are running or dealing with there must be specific requirements in place to ensure that they are performing to peak efficiency and that they are resolving customer enquiries in a timely manner. A common industry term for these metrics is KPI - Key Performance Indicator and there are hundreds of different ones depending on the product and service you provide as well as what you want to measure and what is most importatn to your business.


Now each of these teams would have different metrics in place. However some that are common to both Customer Service and Technical Teams are as follows:
Response Time - Obviously your team (Incident Management/Customer Service/Helpdesk) needs to get back to the customer in a timely manner. Their goal as already mentioned is to fix it, fix it fast and move on. A band-aid will not always reattach the finger though, so it's up to the Tier2 team to ensure that the surgery goes smoothly which obviously takes a lot more time as you don't want the surgeon doing a shoddy job!


So with that analogy in mind ... you want to have an aggressive goal set for your Helpdesk – try to work with the 80/20 rule (The Pareto principle) ... 80% of incidents responded to in 20 seconds (If you have the resources, otherwise maybe 20 minutes? Or 20 hours (that's less than 1 day so might still be good – especially if you're doing email support)? Or 20 days ... well that's probably not really worthwhile) but hopefully you get the point? You want to set a specific goal for measuring how quickly your customers are getting a response.


Resolve Time – notice that I have separated these out. As much as you'd like to be able to resolve 100% of issues at that first contact, its not always going to be possible. However you can have another measurement in place that tracks this which is the Resolve Time (sometimes called MTTR (Mean Time to Repair)).


The Goal here is also to get that band-aid on as quickly as possible so you need to ensure that your Incident Management system has some sort of a knowledge base which helps your staff find the solution to commonly placed issues/questions. If they have the answer every time, then a 100% resolution at 1st contact is achievable! If not however ... it gets a bit more complicated because all of a sudden your Incident Management team becomes the customer and the team they go to is the Problem Management team. Guess what? They have a different measurement for Response Time and Resolve Time too!


Problem Management Response Time – now as previously mentioned these are generally your more senior staff and as much as you'd like them to be available 24/7 unless you have an extremely large organization this is probably fairly unlikely. So you are going to have build or determine some relevant response times based on their availability.


In addition, as these escalated issues are generally issues that cannot easily be resolved, your resolution time is going to be extended also. Pick some appropriate intervals that meet your customers SLAs.
Your main goal for this team (in addition to resolving the problem of course) is communication, communication, communication!!! They must inform your customer facing agents what the issue is, what they are doing to resolve it and when they expect to have it resolved. If they cannot provide an estimated resolution time, they MUST provide your Tier1 team with an estimated update time.

Setting up and Launching a Remote Office

In the early days of my career I was responsible for setting up an operation in a different city. It was a great opportunity for me and some...