The Path to Revolutionizing Your Technical Support

Written by PayPerShop.com - Filed under: Articles on May 19th, 2008

By Randy Miller, Director of Services, Journyx

One of the hats hanging on my office wall says ‘Technical Support Manager.’ I have managed technical support at a software company for seven years now, and in that time, I have had to discover a way to revolutionize the team and its effectiveness for the benefit of the entire company. I was able to eventually hit upon a winning plan, and this article series will outline that plan as well as offer advice on how to implement it in your company.

Where You Are

If your technical support department is anything like mine was seven years ago, you may be having trouble hiring the right kind of staff. After all, most people think of tech support as a dead-end job where all you do all day is listen to people complain. In addition, people in other areas of the company might be blaming technical support for customer complaints. They don’t see how it could possibly be fixed, so you can’t get any budget to fix it. Does this sound about right?

The complaints can end. You can even get credit for your team’s helpfulness and hard work. All it takes is a few steps in the right direction, and here’s how to begin.

Moving Forward

Technical support is like a team of jugglers trying to simultaneously balance all kinds of items. This requires great communication throughout the team, and here are four important processes involved in getting it right.

Code Red
The first issue to address is what case priorities will look like. If you already have this information in your maintenance contracts, then you don’t have to worry about it, but if not, sit down and decide what constitutes an urgent case and what doesn’t. I suggest you formulate 3-5 categories of case severity and then choose service levels for each—how quickly you intend to respond and how quickly you will fix.These priorities must be discussed with your team so that someone is always keeping an eye on incoming cases and properly prioritizing them.
Saving Time
It is not always possible to solve problems so that the customer never sees it, but you can do the next best thing, which is to publish the fix and let customers solve problems themselves. Drafting a rough version and copying-and-pasting it to the customer takes the burden off of you. Every time you use that draft, refine and edit it once again so that in the end, you will have templates that are ready for public publishing.Check with senior management to see if you can publish the problems and solutions in a public knowledgebase, allowing customers to help themselves. Getting that documentation into your customers’ hands will really save you time that could be better spent elsewhere (researching new fixes, for example).
Fix It Yourself
You need to have your own developer in technical support. If you don’t, then I imagine you know how hard it can be to ask for bug patches and low-level design changes from an already busy development team. When you have your own developer, however, you start getting those low-level design changes, which are more useful than you could have imagined. You also get neat tools to fix bad data and new investigation tools. Think about it: a developer who is focused exclusively on tech support will do things that an interrupted developer would never do, including fixing things that you didn’t know were broken.
Teamwork
In order to maximize your resources, the team is going to have to work together towards embracing new attitudes. These attitudes include:
- I am responsible for getting the problem fixed and the solution documented.
- I understand that customers might be angry, and I need to use my voice and calm words to help them calm down.
- I will not blame the customer for the problem.
- I will not accept abuse from the customer.

I once had the opportunity to demonstrate the right professional attitude for my team when I fielded a call from an angry customer. I don’t remember the specific details, but he had broken our software, called in and was being abusive to one of my people. I decided to take the call and calm him down. He was cursing and yelling, so I apologized for the problem. He cursed at me again. I said to him, calmly, “I understand why you are frustrated and I want to help you. But if you continue to curse at me, I will hang up on you.” Well, he cursed again, and I kept my word. I then called his company and asked if there was someone else I could work with to resolve the problem. There was, and we got the problem fixed in a matter of minutes.

This helped my team to stand up a little straighter and feel confident in demanding to be treated professionally. Our pride in our work increased, as did its quality.

Where You’re Going

Revolutionizing your technical support team cannot be done without figuring out not only where you are today, but where you want to be going. This section provides sample goals you can set for improvement.

Current State

How many cases does support receive each week? How many cases do other departments handle?
How many customer complaints reach the executive team each week?

Short-Term Goals

Get approval to reinvent the technical support team.
Choose your tools and implement them.

Medium-Term Goals

Keep all tech support calls within the team.
Resolve problems before customers get angry.

Long-Term Goals

Lower support costs (per product line, product launch, customer and customer attribute).

How You’re Doing

After defining your goals, you will need to find a way to measure all of their components. To do this, you should implement a helpdesk tool that will give you a set of reports on the number of cases opened and closed per day/week/month, the amount of time spent on each case and the aggregate cases per customer.

You will also need to keep an eye on your workload in order to predict potential problems. Plot your number of monthly cases against how fast your team is resolving them on a graph. This will help you to understand, for example, the effects of a new release on your department. Generally it will increase the number of cases due to new bugs and decrease the speed of solving them as your staff get up-to-speed on the new version. Knowing this in advance allows you to hire temps or make sure none of your team members take vacation. If you can foresee it, you can prepare for it.

When the long-term trend lines are about to cross, you will know that it is time to hire more staff. For more on that process, tune in next month for Part 2 of this series.

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.

Written by PayPerShop.com - or reproduced on behalf of the company supplying the above information.

Filed under: Articles on May 19th, 2008