This post will focus on what I call the Service Desk. For those of you in the know you will realize it is a very loose interpretation of the ITIL framework. What I am describing is actually a help desk. I am using the Service Desk term for most help desks today have become helpless desks due to bad management and execution. This is my attempt to right the wrong. I make no apologies for using the term Service Desk.
The goal of a Service Desk is to offer good service and not to be a burdensome process. The graphic above is the high level view of the Service Desk. Some other goals of the service desk are to record the resolution and to offer self-service to those users who wish to do so. The Service Desk should be accessible by any channel. The most common channels are email, web site and call center. By having multiple channels the user is able to make contact even if their computer is completely inoperative.
As you have probably guessed from previous posts I am a process person. As such when a process is intuitive and effective it will be used. When a process is broken or ill conceived it will not be adhered to. I say this to remind the readers if your Service Desk is not being used, the normal culprit is an ineffective Service Desk (or helpless desk as mentioned earlier). The entire management team must support the process and adhere to the process in order for it to work. The Service Desk has several levels and each level has a contact path and a responsibility path. I will endeavor to explain as I go along.
Please refer to the graphic as I explain the roles and their associated goals. As mentioned before the Service Desk should have a website for the users and the managers to monitor their requests. Users should be able to email requests. I use the email address of “firstname.lastname@example.org” as the moniker for email access to our Service Desk. I also have a phone number for users to call to get their requests in. It is imperative that the users shouldn’t have an intimate knowledge of how your service desk works. They just need to know how to access it and watch for progress. If you offer too many options, then the user community gets confused and starts circumventing the process.
As a downstream process it is imperative the organization has a Service Desk that is accessible to all parties and is the single source for all requests, changes and issues. Failures to do so can cause many undo delays and multiple touches on the requests. This is another sign of an overburdened process.
This is the actual person with the problem, issue or request. It must be impressed on them to give as much detail as possible and how and when they can be reached. Some systems will allow the user to dictate priority and I am not a big fan of this for it gets over used. I tend to ask questions that state importance. For example is your system down? Are you able to perform your work by other means?
The user can call the Service Desk or email the request or place an entry at the website. Regardless of how the entry started it will be visible to all concerned parties via the Website. This is critical. For the purposes of the rest of this post this request or entry will now be called the work order.
- Role – Enter the work order and be as descriptive as possible
- Responsibility – To ensure all work instructions have been followed and that first level operating procedures have been followed.
The immediate supervisor of the user should now have access to the work order. If required they should be able to make additions and/or comments to the work order. If the work order is a change request, my process forces the immediate supervisor to approve the work order for review. The work order will be routed to the business analyst and from there a formal approval process will commence. For the purposes of this post I will not delve any deeper into the approval process other than to say, you should have one for change type work orders.
- Role – update the work order and provide insight and guidance to proceed.
- Responsibility – To supervise the work order process and to ensure that it is a valid work order to be worked on. If it is a training issue they must instruct the user correctly and update the work order accordingly.
This is the Single Point of Contact (SPOC) for your Service Desk. This person does NOT have to be a technical person. It is helpful but not a requirement. Their goal is to ask pertinent questions and to gather more information for the other players in the process. Over time, the Service Desk will become a resource center and this Tier 0 individual will be able to solve most simple problems. Issues like password resets and hardware resets can be handled by this group. These issues are always following established protocols and guidelines as set out by the Technical Department.
Many times Tier O can be located at a remote office or business unit. For some organizations this Tier 0 is an operational person and an operational responsibility. You will need to assess the value of this approach. It works in a lot of organizations that share an IT pool. This gives the IT pool a pre-filtering before they are engaged.
- Role – To look at work order and gather information to pass it on to other groups. If more information is needed then they make contact with the user to gather this information. They can also determine the severity of the issue and any possible work arounds.
- Responsibility – First formal contact with user. They must have an excellent customer service approach to working with the end users. They are encouraged to apply known solutions to problems. They are the only ones who can direct the work order to the specific support groups. They must also contact the end user via a determined channel that the work order is being addressed. I am a big proponent of always informing the user as to status. This role will also update the work order with all its findings and actions performed to date.
This is the first full time technical contact to the Information Technology Department. It is equipped with junior level support people. It is usually the starting point in most technical department. They will have more tools and resources then the Tier 0 group. This is effectively the Triage group. They ascertain what type of issue is this. Is it hardware, software, network, security etc. Once this is determined they will perform first level support on the work order. They will update the work order and ask the user to perform known solutions to the issue. They will also try to gather any information from any failed attempt to resolve. Sometimes a lot is learned from failed attempts. Due to the direct customer interaction, you must impress in this group good customer service protocols.
- Role – To look at work order and gather information to pass it on to the Tier 2 group only when first level solutions have been exhausted. If more information is needed then they make contact with the user to gather more information. They can also confirm the severity of the issue. This group is a technical group and as such must be able to quickly inform the deeper support tiers of all the troubleshooting to date.
- Responsibility – First formal technology contact with user. They should have a customer service approach to working with the end users and Tier 0. This role must dig deeper and use the OODA loop throughout this process. This role will also update the work order with all its findings and actions performed to date.
This group is the subject matter experts of their respective areas. This is to say they are experts in software applications, hardware, networking, security and any other technical areas your department is responsible for. For smaller shops an individual may wear many hats but regardless they are considered the expert for a particular area. They may also be the backup person for another specialist in another area.
Tier 2 only speaks to Tier 1 and Tier 3. A proper rollout will not have them speaking to end users. This on the surface may seem odd but what I have discovered is that you pay these people to get the work done and not to be confused by the end user. Also, many of these specialists do not play well with others and therefore tend to annoy end users. There are always cases when they have to speak to end users but I try to discourage that. Trust me; things work better when they are dealing with likeminded individuals.
This Tier like other tiers updates the work order with what has been done. If they cannot solve the problem they can pass it on to another specialist in this group if they believe the problem is theirs or they can pass it to the actual vendor that is responsible for the work order issue. This latter group could be a software company or hardware vendor or network management group. It is typical to send the work order details to the supporting vendor to reduce their efforts and to stream line the resolution process for all parties.
- Role – The subject matter experts of a specific area or areas. To fix the problem permanently and to update the solutions database with the resolution. To escalate to vendors if needed
- Responsibility – Primary contact is with Tier 1, 2 and 3 and not the end user. They must have the skills to fix the problem and to research resolutions using all the resources available. They are the only ones who can direct the work order to Tier 3. This role will also update the work order with all its findings and actions performed to date.
This is the actual vendor and is typically outside the organization. It is in everyone’s best interest if the end user does not contact the vendor. This leads to dysfunctional behavior, increased support costs and lack of knowledge on how the issue was resolved for future issues.
Most vendors will support this model for it allows them to treat your tier 2 group as their tier 0 group and thereby reduces their time to resolution.
Most vendors will not have the ability to update your work order directly and therefore your tier 2 will have to update the work order with the details for future reference.
- Role – To address the deeper issues with the work order request. To work with your tier 2 to resolve any issues.
- Responsibility – Typically the support of last resort. If your organization cannot fix the issue then the vendor must resolve. They need to be respectful to the fact the problem has already been worked on and that there is no need to start from ground zero even if they want to. Your organization has to pass on all the relevant information to the vendor.
At first blush it may look like this is just another process to annoy the end users. In fact in can be if you do not have the discipline to maintain the protocol. However, if your organization has the discipline and your Technology Department is successful in solving the issues then you will find compliance high and the results positives. I have been in many shops where everyone called whom they believed could solve the problem. The problem with this approach is that it assumes you have called the correct person. If not you may have called a mechanic to fix an electrical problem.
The Service Desk also protects your group. By being transparent you will not get into the argument that your department is not fixing issues. You will need to be firm and keep stating you can only fix problems you know about. This statement means you keep telling your users to fill out a work order. We, in my department, log all things into the work order system, even if it was just a 2 minute fix. By doing so, I have the metrics of what my team is doing and the end user has a transaction to confirm a service was provided. The work order system serves all parties well when all parties decide to use it honestly, completely and effectively.