How to Reinvent Your Technical Support Team
August 26, 2008
I have two hats hanging on my wall. One is labeled “Professional Services Manager,” and the other is labeled “Technical Support Manager.” I have been managing the technical support team at a software company for about seven years. When I began, we were hemorrhaging angry customers. Now we haven’t received a legitimate customer complaint in years.
My training and experience was in sales and retail management, so when I took on the position, I asked the CEO and VP of Sales what they wanted from the tech support team. Here’s what they said:
- I’m tired of getting yelled at by customers for our lousy support.
- I’m tired of seeing the salespeople doing technical support instead of selling.
With those marching orders I flubbed, fumbled, and failed for a while. It took me a few months to hit upon a winning plan and about a year to get it actually running. Looking back on the experience, I see a few key elements that I should have done earlier and a few mistakes that I should have avoided. In this series of articles, I will give you that plan and practical advice on how to put it into action.
Why Reinvent in the First Place?
The technical support industry has always gotten a bad rap. No one wants to spend all of their time listening to people complain, and most people view it as a dead-end job. For managers, this means that in your pool of candidates, the pickings are often slim. You can only hire people who can’t get jobs doing anything else. These people, as you can imagine, move on quickly.
Sometimes these issues cause pressure between technical support and other areas of the company. Other departments might blame your team for all of the customer complaints. No one considers how effectively ending the complaints would reinvigorate the company. They don’t think it can be fixed, so you might not be able to get any budget to fix it.
Sound familiar? If this is the state your tech support department is in, then reinvention is your only option for improvement.
The Change
1. Before you begin, you might want to ask for feedback from other entities within your organization, as I did. Knowing what other executives expect from you, as well as what they expect technical support to accomplish, keeps everyone on the same page and ultimately benefits the organization more than if you tried to reinvent it in a vacuum.
2. What constitutes an urgent case? What constitutes a case that you can get around to next week? You need to make decisions on these issues and then communicate them to your team. Create 3 to 5 categories of case severity, as well as service levels for each. Also, take a look at your contracts—they will likely have existing service level agreements that you can use instead of creating new ones.
3. Publishing fixes and letting customers solve problems for themselves is a great way to save time, and as you know, time is crucial when it comes to support cases. If you are unable to document the solution in a generic way and provide all of the necessary technical details, you can temporarily write up a rough version of the solution and then copy-and-paste. The vast majority of your cases are issues that you have seen before, so doing this gives you more time to research new cases.
At my company, Journyx, we created a knowledgebase—a time consuming task, no doubt, but a worthwhile one that yielded enormous benefits. We began with a big text document on a shared network drive and eventually moved to real helpdesk software that had a knowledgebase feature built in. If your management will allow it, you should also consider publishing problems and solutions on a public knowledge base where customers can help themselves. You can always gate it, but getting that documentation into your customers’ hands means you can literally solve problems in your sleep
4. If you are a software company, you need developers on your technical support team. You will not be able to attract a developer unless you have a fairly professional organization working already, so get some successes under your belt and swagger in your step before you take this plunge. (We’ll talk more about how to hire this developer in Part 2.) When you do hire them, it will change your life forever.
Relying on an already busy development team for patches is problematic. A developer who is hard at work on some fun, new code is not going to want to stop and fix your bug. When you ask for a low-level design change to prevent customers from getting into this mess, the developer gives you a better error message. Then you say some bad words to each other.
When you have a developer on your team, you start getting the fixes and low-level design changes you’ve been begging for. Not only that, but your developer will find and fix things that you didn’t understand were broken—underlying causes for problems that were too deep in the code for you, a non-developer, to understand.
The New Mindset
Reinventing technical support requires changes from within. More than reorganization, you will need to ensure that your team will embrace the changes and have the right kind of attitude for success. This attitude includes taking responsibility for fixes as well as for documenting them, being understanding and courteous with angry customers, not accepting abuse, not blaming the customer and not fearing the phone. This won’t happen overnight, so put up posters, talk with your people, and praise and reward them when they pick up the new attitudes.
It is easiest to achieve this by being a player-coach. Answer some support calls in front of your team, or take them out to lunch and tell them stories about how you handled certain situations. Attitude can be contagious, and they have to catch it from you.
Hitting the Mark
You will also need to ascertain your support team’s current state so that you can effectively set short- , medium- , and long-term goals for the future. Consider how many cases technical support receives each week, how many cases other departments handle each week, and finally, how many customer complaints reach the executive team each week. This will give you a pretty good idea of where you’re at and where you should be heading towards.
Short-term goals for getting the entire process started include obtaining approval to reinvent the support team, choosing the new tools you will use and putting them into place. Medium-term goals that will get support under control include handling all technical support calls within the team and getting problems resolved before customers become angry. Finally, long-term goals that enhance ongoing improvement include understanding and reducing support costs per product line, product launch, customer and customer attribute (e.g. market, size, industry, salesperson, title of primary contact, etc.).
Understanding your cost per customer attribute is critically important, and context will make that data really meaningful to the company. The best way to get that context is to pair up the cost per customer data with income per customer data, which will yield profit information. You will find that your profit is lumpy and uneven because some types of customers are more expensive to support. You should eventually present that data to senior management so that they can make profit-maximizing decisions about pricing and product direction.
The Right Measurements
After defining your goals, it will be necessary to measure all of their components. You can implement a helpdesk tool (more on this in Part 3) that will provide reports on how many cases are opened and closed per day/week/month, how much time is spent on each case, and aggregate cases per customer.
For more advanced goals, you will need to more advanced reports. You can get these by either connecting your helpdesk to your CRM and/or accounting system, merging CRM and accounting system report data with helpdesk report data, or duplicating CRM and accounting system data in your helpdesk.
In addition to measuring progress, you will also need to measure support workload in order to know when you need more staff. Over time, it is likely that your number of cases will increase (more customers and features leads to more complexity). Your support staff will also become better and fixing things faster. You must plot these two trends on a graph monthly. Knowing how many minutes each support case takes on average will allow you to plot them in terms of minutes per day.
This graph will allow you to see how, for example, a new release can temporarily increase the number of cases (new bugs) and decrease the number of cases you can handle (as your staff get up-to-speed on the new version). Knowing that ahead of time allows you to prepare for such incidents by making sure none of your staff takes vacation during a release or hiring temp workers. When you notice that the long-term trend lines are about to cross, you need to hire more staff, and Part 2 of this series will guide you through the process.
About the Randy Miller: Randy Miller has 11 years of customer-focused experience in sales and services delivery. Prior to joining Journyx in 1999 as the first timesheet-specific sales rep, Randy spent five years in the Corporate Sales and Retail Management divisions of leading electronics retailer CompUSA. Since then Randy has held many different positions at Journyx, including: Sales Engineer, Trainer, Consultant, Product Manager, Support Team Manager, and Implementation Manager for Enterprise Accounts. Randy has personally managed development and implementation efforts for many of the company’s largest customers and is a co-holder of several Journyx patents. Randy was named Director of Services in 2005. Randy can be reached at randy@journyx.com.
Image courtesy of lumaxart and used under the GNU Free Documentation License.
Comments
One Response to “How to Reinvent Your Technical Support Team”
Got something to say?
Randy, great post -
I have also worked in the software industry for many years. The one organization that I worked with that had an amazing support team practiced one extra detail.
As you state - motivation and skills in the “dead end” seeming tech support field often leave much to be desired.
At this organization - the tech support team was our “Top Gun” team. Employee Turn Over is usually considered a negative, but when that “Top Gun” turnover was into our Development, QC, or Professional Services teams - we considered it a success.
And knowing that other opportunities exist made it a great help in recruiting to fill the void.
So not only did these team members who moved on have direct experience on the other end of a support call - in their new roles, they could actually assist in reducing support issues.