1. Don’t: Configure the help desk application in a vacuum
You can imagine how difficult it is for a dedicated help desk manager to be gung ho about their new product and processes, spending hard-to-find time with great intentions designing something they think will accomplish the needs and goals for their service center, only to find out they’ve missed the mark completely. Reality is that a lot of people interact with the help desk and their needs for data from the application can vary wildly. Not taking those perspectives into account and having a myopic view on configuration is a sure-fire killer to the success of your new plans.
Do: Design and configure in a team environment and build it together. Be aware that your application is probably powerful enough to be used by other departments. Check with members of HR, procurement, facilities, etc. to gather their input at the beginning and see how seamlessly processes are adopted and utilized when everyone gets buy-in upfront.
2. Don’t: Implement too much of the application too fast
Solution feature sets today cover wide ranges of functionality such as incident, problem, change, asset, knowledge, service levels, customer self-support, reporting, and more. Implementing everything at once may make your support team feel like you’re trying to wash their faces with a fire hose. You end up with staff trying to use a new tool they are not familiar with, getting requests from users on how to do things, and becoming frustrated. You inadvertently create a culture of confusion.
Do: Implement gradually! Pay particular attention to how technically savvy your staff and users are. Start by getting your techs up to speed on basic incident and knowledge management features and then go from there. As a good rule of thumb, allow 30-60 days between enabling additional functionality. Also, don’t overuse the notifications. If a technician is flooded with an email every time an action is taken on an incident, the importance of those notifications is lost in the massive amount of mail received.
3. Don’t: Under estimate the power of knowledge management functionality
You have as much investment in your staff as you do in your ticketing system. Why incur the loss of that investment when the eventuality of employee turnover occurs? Not using the knowledge management capabilities of today’s solutions only exacerbates the problem and makes techs continually reinvent the wheel. Oftentimes the problem is simply a lack of communication about whose responsibility it is to capture the knowledge.
Do: Begin by realizing there’s a greater long-term cost to continually re-engineering the technical know-how of your support staff than there is a short-term cost of establishing an efficient and automated process for capturing and categorizing knowledge. Designate a weekly knowledge approver and give that person a specific day and time to maintain the knowledge base. This harvesting of knowledge will save you time and money in the long run.
4. Don’t: Categorize at too granular a level
Your new help desk software probably has the ability to categorize tickets to varying degrees. Many service teams get far too granular in their level of categorization. When this occurs it creates an inefficient use of the data you are collecting as well as excess clicks. It also often confuses techs who have to scroll through endless tree structures looking for the proper category to assign to a ticket.
Do: Think of what is most important for you to report on. Hardware failures? Printer failures? Training? If your application has decent searching capabilities, you don’t need to categorize to the nth degree. Start out with the minimum requirement of your reporting structure and add on later as the need arises. To assist in building a solid category structure, leave out actual problems, like “can’t print” as a level – that information goes in the Description field. If you find that for every category you are being redundant in your lowest level, you might be using a category field for data that needs to be captured elsewhere – such as a ticket level custom field. You might even consider inverting your category list!
5. Don’t: Fail to create an end user or customer self-support portal
There are definitely organizations where self-support does not fit. If your company is already capturing valuable knowledge content and your users are fairly tech savvy, though, you are costing your service desk time and money by not making that information available to your users. Why encourage calls if the users are able to help themselves?
Do: Create specific portals/desktops for your various sets of users. Allow them to view knowledge/FAQs and submit their own tickets. Be prepared to have to evangelize this new means of self-support to foster us¬age.
6. Don’t: Overlook importance of multiple escalations and notifications (SLAs)
Escalations, notifications, and service level agreements (SLAs) are fundamental parts of providing excellent support. Many of today’s help desk applications allow you to set up very complex, fully-automated SLAs, but oftentimes support desk personnel don’t take the time to set them up accurately or thoroughly. Tickets should not escalate and notifications should not be sent unnecessarily. They are also not one size fits all; an order request shouldn’t escalate the same as a “something’s broken” ticket.
Do: Use care in building your escalations and SLAs, and set up notifications according to the actions required. Identify the special cases where time is a factor, such as a critical hardware failure. Use caution when applying a time-sensitive SLA; for example, if a mail server fails, how will notifications be effective if they can’t be delivered? A page notification could be used instead.
7. Don’t: Let your product choice drive your process
If a help desk software application is so complex that you have to change all your processes and service culture, there will be too many costs involved and not enough buy-in from users. This often leads to the out¬right failure of the implementation.
Do: Don’t be too consumed with standards or immense feature sets. While you may feel like it’s a safe play to buy something that’s “standard certified” or has the most bells and whistles in the industry, if it doesn’t fit with your processes or culture and prove to be easy to use and manageable over time, it’s ultimately your job on the line if it fails.
8. Don’t: Under utilize templates and auto-population
Let’s face it, your service center directive will always be to do more with less. So make sure your staff are not manually entering data that can be pulled in automatically, or typing the same information again and again on common tickets.
Do: Create the most efficient and automated use of your staff’s time by setting up templates to record frequently occurring issues. A good templating tool that uses dependencies can be even better, especially if you can tie approvals to templates.
9. Don’t: Overuse queues
Many service desks will use queues to assign tickets to a group, which often results in everyone thinking the other person is working on the ticket. This common occurrence often causes confusion and misuse of time. This lack of accountability and confusion is easily avoidable.
Do: Designate someone to monitor the queue, reassigning incidents as appropriate. If your help desk software allows, use a distribution method that automatically assigns incoming incidents to remove the chance of incidents being overlooked.
10. Don’t: Be process rigid or bad practice addicted
Not to be confused with #7 above, don’t be afraid to evolve your service processes either at the implementation of your new help desk application or over time as your use of it changes and grows. Too often, when a software package is rolled out, it feels easier to simply get it going yet continue with the status quo service processes. This can create an inefficient use of the new package’s feature set.
Do: Change is often inevitable, so try to keep a fluid mentality towards the processes you rely on in your service center. Re-evaluate your procedures on a set basis (i.e. yearly or every two years) and determine if they still apply. Try not to carry forward processes or procedures just because ‘that’s how it’s been done in the past.’ Any good help desk software vendor will continually work to increase the power and efficiency of their solution, so don’t be so rigid in your ongoing processes that you aren’t willing to consider evolving them over time. Also, leverage content delivered from thought leaders in the industry to see how others are evolving their processes. Read whitepapers, search industry portals, attend industry events, view industry blogs, etc. to gain valuable insight.
11. Don’t: Sacrifice training your staff
Nothing undermines your service efforts faster than under-educated help desk staff. For example, if a technician isn’t aware that ticket information is automatically emailed to the customer, the wrong information can be released, causing irreparable damages. If they are un¬aware of what the SLA time values are for each priority, tickets can be misprioritized and agreements can be missed. If techs are unaware of the category structure, they may not know how to categorize a call without having to do a lot of searching for the correct selection. The possibilities for inefficiency and waste are too numerous to consider.
Do: Seek out training opportunities for staff in need, and be sure they are educated on the specific options available to them in your help desk software and the effect of those options. Remember that it’s easier to train/educate your people than it is to apologize for bad information sent to a customer. Also, put an emphasis on increasing the accuracy of your ticket information – for example, don’t include work history information in a ticket resolution because the resolution can be used on a knowledge entry. It’s not useful to read things like “called and left voice mail” when searching for a solution.
12. Don’t: Cut the communication ties to your help desk software vendor
If your service desk is not utilizing the full functionality of the help desk application you’ve purchased, you are not experiencing the maximum ROI available to you. If you have a feature request that could make usability more favorable, your vendor should be requesting that information from you on an on-going basis. If your staff are not proficient in the use of your help desk application, greater gains may be available with minor investments in training.
Do: Call your help desk software vendor and communicate your needs. When you have only partially implemented your tool, put an emphasis on seeking help to get it 100% optimized. If you have a vendor that doesn’t respond in a favorable or timely manner, con-sider that the next time your software is up for renewal. These soft costs are just as much a part of the value of your solution as the purchase price.
No comments:
Post a Comment