The technical support industry has always been in a death-spiral. No one wants to spend all of their time listening to people complain, so managers can only hire support staff who can't get jobs doing anything else. Such people don't really care about the work, get sick of all of the complaining, and eventually move on.

Low staff quality, not to mention motivation, makes it hard to improve the department. It is generally blamed for all customer complaints. No one thinks anything can be done about, so managers can't get any budget to fix it.

What if I told you that there is a way to end the complaining and to receive recognition for your team's hard work? All it takes is a little ingenuity in terms of organizing a new and improved technical support team.

Taking the Plunge

Technical support is a team process. It is like a team of jugglers, juggling all sorts of random items: bowling balls, flaming batons, knives. You need to know when a baton or knife is heading your way. You need to know who can catch the piano. Fortunately there are three processes you can implement in order to facilitate the communication required to do this jugglingand your staff won't even realize that they are communicating.

" First Things First

You will need to make some decisions about priorities and then communicate them to your team. What constitutes an urgent case? What constitutes a case that you can get around to next week? I suggest that you formulate 3-5 categories of case severity. For each, decide how quickly you will respond and how quickly you can fix. There may be a set of priorities in your maintenance contracts already, and if there is, then don't bother reinventing that wheel unless it is utterly unworkable.

When you discuss this with your team, make sure that they understand that top priority cases must be addressed first. The first person to deal with a case has to prioritize it immediately, and everyone on the team needs to know who the backup is.

" Write it Down

The fastest way to resolve a case is to fix the problem so that the customer never sees it, but often times, this is not an option. The next best thing is to publish the fix and let customers solve the problem for themselves. Writing up the solution in a generic way and providing all of the necessary technical details is hard work (not to mention time-consuming), so in the interim, you can 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 built a knowledgebase. This took time, but the rate of return was fantastic. Our first attempt was a big text document on a shared network drive that held about a hundred problems and solutions. Afterwards, we were able to implement real helpdesk software that had a knowledgebase feature.

This is a very important part of organizing a winning tech support team. Every time you resolve an issue that you haven't seen before, you must stop and document the problem and solution in a general way. Do it immediately while all of the details are fresh in your head and you still have all of the test sites. Grammar-check and spell-check. Make sure that the steps to resolve are clear and concise.

If your management will allow it, publish the problems and solutions on a public knowledgebase where customers can help themselves. You can always gate the knowledgebase to restrict access, but getting that documentation into your customers' hands means you can literally solve problems in your sleep.

" Fix It Yourself

If you are a software company, then you need developers within your technical support team. Having them will change your life forever. No longer will you have to fight with developers to give you patches when they would rather be working on some new code. All of a sudden you start getting those low-level design changes you've been asking for, and you find out that they are more useful than you could have imagined. You also get neat tools to fix bad data and new investigation tools. I will never again manage a technical support team without at least one full-time developer.

Altering Team Attitude

You will need to inspire a new attitude within the team in order to make the changes you want. You can't do this all at once, so put up posters. Talk to your team about these new attitudes. Praise and reward your people when you hear them picking up the new attitudes. Here are some of the values you want to instill in them:

" I am responsible for getting this fixed.
" I am responsible for getting the problem and solution documented.
" I am responsible for getting a permanent fix implemented, whether I write that fix myself or manage the process of getting someone else to write the code.
" I understand that people are frustrated and angry. They aren't angry at me, so I won't take their anger personally.
" I will empathize with the frustration that my customers feel, and tell them that I understand and share their feelings.
" I will not accept abuse.
" I will not blame the customer.

The new attitude is easiest to convey if you are a player-coach. Answer some support calls and let the team hear your attitude, or tell them stories over lunch about how you handled a certain situation by taking responsibility. Attitude can be contagious, and they have to catch it from you.

Setting Goals

Overhauling your technical support team is a major project, so you will need to understand your current state and then set short-, medium-, and long-term goals for improvement in order to do it effectively.

Current State - How many cases does the tech support team receive each week? How many cases do other departments handle each week? How many customer complaints get to the executive team each week?

Short-Term Goals -
" Gain approval to proceed with organizing a better technical support team.
" Choose your new tools and put them in place.

Medium-Term Goals -
" Ensure that all tech support calls are handled within the team.
" Solve problems before customers get angry.

Long-Term Goals -
" Understand and reduce support costs per product line.
" Understand and reduce support costs per product launch.
" Understand and reduce support costs per customer.
" Understand and reduce support costs per customer attribute (e.g. market, size, industry, salesperson, title of primary contact, etc.).

Understanding your cost per customer attribute is critically important, and you will need to gain context to make that data really meaningful to the company. The best way to do this is to pair up the cost per customer data with income per customer data, which will allow you to see profit information. You will find that your profit is lumpy and uneven because some customers are more expensive to support than others. Over the long term, presenting that data to senior management enables them to make profit-maximizing decisions about pricing and product direction. Everyone wins!

Measuring Progress

Setting goals is useless unless you have some way of effectively measuring progress towards those goals. Implement a helpdesk tool (more on this in Part 3) which will give you reports on:
" Number of cases opened per day/week/month.
" Number of cases closed per day/week/month.
" Amount of time spent on each case.
" Aggregate cases per customer.

In order to achieve more advanced goals, you will need to develop some advanced reports. This requires either duplicating most of your CRM and accounting system data in your helpdesk, connecting your helpdesk to the CRM and/or accounting system, or merging CRM and accounting system report data with helpdesk report data.

As you get better at meeting your new goals, you may find that it is time to hire more staff. Check back for Part 2 of this series, which will guide you through the process.



About the Author:
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.