Home Leadership Skills Designing A New, More Effective Technical Support Team
US FTC Compliance
Yes, all these ads are some kind of affiliate link and I get paid a commission if you click or buy.
Not enough to quit my day job, but it keeps the site alive.
- Jeb Riordan, Editor, PROJECTmagazine
Designing A New, More Effective Technical Support Team Print

When I inherited the tech support team at a software company seven years ago, we were hemorrhaging angry customers. Since my experience was in sales and retail management, I asked the CEO and VP of Sales what they wanted from the tech support team. They had two answers for me:
- I'm tired of getting yelled at by customers for lousy support.
- I'm tired of seeing salespeople do technical support instead of selling.


Through some trial and error, I eventually found a winning plan, and this series will offer practical advice on how to put it into action in your company.

Why Redesign Your Team?

Everyone sees technical support as a dead-end job. After all, nobody wants to spend their days listening to people complain. Consequently, you are forced to hire people who can't get jobs doing anything else. They eventually get sick of the complaining as well and move on.

Such low staff quality and motivation undermines any attempt to improve, and people outside of the team often blame technical support for customer complaints. The good news, however, is that complaints can end. Better yet, you can start getting praise for your team's helpfulness, and follow-on sales and referrals will increase, but only if you redesign your team the right way.

The New Look

Imagine technical support as a team of jugglers trying to balance bowling balls, flaming batons, knives and other random objects. You need to know which is heading your way, and who will be able to catch it. This requires communication throughout the team.

Triage

The first thing to determine is how to triage incoming cases by deciding what constitutes an urgent case and what doesn't. Create 3-5 categories of case severity and decide on service levels for each-how quickly you intend to respond and fix. If you already have an agreeable set of priorities in your maintenance contracts, then stick with those.

Talk your decisions through with your team and make sure they understand that top priority cases must be addressed first. Someone must also pay attention to incoming cases in order to prioritize them immediately and treat them appropriately.

Document Solutions

New tech support cases constantly appear while you are still working on current ones, and the longer your current case takes, the more new ones appear. Saving time can help you get ahead of that curve. Every minute you save on your current case counts because you can get into and out of the next case that much sooner.

The fastest way to resolve a case is to fix the problem so that the customer never sees it. If you can't, the next best thing is to publish the fix and let customers solve the problem. Providing all of the necessary technical details is time-consuming, so in the meantime, you can write up a rough version of the solution and copy-and-paste. The vast majority of your cases are issues that you have seen before, so this shouldn't be difficult to do, and you will then have more time to research new ones.

Every time you resolve an issue that you haven't seen before, 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 and resources at your fingertips. The first few times you copy-and-paste that answer out to someone, double-check that the instructions are general enough to suit the customer. If not, edit the original document and improve it.

If management allows it, publish the problems and solutions in a public knowledgebase where customers can help themselves. You can restrict access to paying customers only, but getting that documentation into their hands takes the burden off of you.

Get Developers

If you are a software company, you will need developers within your technical support team. If you are used to punting bugs to the development team for patches, then you know why. A developer is hard at work on some new code when they have to stop and fix a bug for you. You ask for a low-level design change to prevent future problems, and they give you a better error message. You say some bad words and stick another needle in your voodoo doll. (All support managers have those developer voodoo dolls; I've asked around.)

When you have your own developer, you can actually get those low-level design changes, as well as tools to fix bad data and new investigation tools. A developer who is focused exclusively on fixing bugs will do things that an interrupted developer would never do. He/she will find and fix things you didn't even know were broken.

The Catch

Once you have a developer on your team, the number of bugs customers experience will drop. Some of your customers may decide to stop signing annual maintenance contracts, saying, "We don't need support; we haven't hit a bug in years." This is a good problem to have, and when this occurs, you simply need to look at your financial model and consider adding other things to your maintenance package.

The New Outlook

Giving your team a new attitude will allow you to make the changes you want. Here are some important ideas they will have to embrace:

- I am responsible for getting this fixed.
- I am responsible for getting the problem and solution documented so no one has to troubleshoot this problem ever again.
- I understand that people are frustrated and angry, but I won't take their anger personally.
- The more upset the customer is, the more I need to help them calm down.
- I will not accept abuse.

It is often best to teach by example, so you might want to answer support calls in front of the team, or tell them stories about how you handled a certain situation by taking responsibility. Attitude is contagious, and they have to catch it from you.

One of the turning points in the rebuilding of my technical support team came when I fielded a call from an angry customer. I don't remember the specific details, but he called in and was abusive to one of my people, so I took the call and attempted to calm him down.

He was cursing and yelling, totally out of control. I apologized for the problem. He yelled and cursed at me again. I calmly said, "I understand why you are frustrated. I want to help you, but I will not if you continue to behave in such an unprofessional manner. If you continue to curse at me, I will hang up on you."

He cursed.

I hung up.

I then called someone else at his company and asked if there was someone I could work with to resolve the problem. There was, and we got the problem fixed in a few minutes.

After that my team stood up a little straighter, knowing that we weren't whipping posts anymore. We were professionals, and we would insist on being treated professionally. Our pride in our work increased, as did its quality. Retelling this story to new team members ensures that the attitude of professionalism is caught.

Setting Goals

Overhauling your technical support team is a large task, and it cannot be done without first understanding your current state and setting goals.

Current State

Understanding your current state is essential in order to gauge progress. Ask yourself the following questions:
- How many cases does the tech support team receive each week?
- How many cases do other departments handle each week?
- How many customer complaints reach the executive team each week?

Here are some short-, medium- and long-term goals you will want to consider for your team.

1. Short-Term Goals

  • Gain approval to redesign the technical support team.
  • Choose your new tools and put them into place.


2. Medium-Term Goals

  • Handle all tech support calls within the team.
  • Escalate calls internally and get problems resolved before customers get angry.


3. Long-Term Goals

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


By pairing up customer data with income per customer, you will be able to draw some important conclusions as you learn which customers are more expensive to support. It can also help senior management make better decisions about pricing and product direction.

Measurements and Metrics

After defining your goals, it is important to measure all of their components as well as your support workload in order to know when you need to hire more staff. A great way to do this is to Implement a helpdesk tool that will give you a set of reports on number of cases opened and closed per day/week/month, amount of time spent on each case, and aggregate cases per customer.

For more advanced goals, you will need to develop advanced reports by either duplicating CRM and accounting data in your helpdesk, connecting your helpdesk to your CRM and/or accounting system, or merging the three.

Staff Levels

Increased customers and features lead to more complexity, so your number of support cases will likely grow over time. Your team should also be getting better at resolving such cases faster. Plot these two trends on a graph and update it monthly. Consider how many minutes each support case takes on average, and then plot them in terms of minutes per day.

These graphs will give you great visibility into your team. For example, you will see that a new release temporarily increases the number of cases (new bugs) and decreases the number of cases you can handle (as your staff get up-to-speed on the new version). You can then use such data to predict support bottlenecks weeks before they occur, and you can prepare for them by either hiring some temps, making sure your key team members don't take vacation during that time, or both.

When you see that the long-term trend lines are about to cross, you will need to hire more staff, and my next article will guide you through the process.

Randy Miller (c) 2008

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 This e-mail address is being protected from spambots. You need JavaScript enabled to view it .

Share/Save/Bookmark
Comments (0)Add Comment

Write comment
bold italicize underline strike url image quote Smile Wink Laugh Grin Angry Sad Shocked Cool Tongue Kiss Cry
smaller | bigger

busy
 
Copyright © PROJECTmagazine (c) 1998 - 2019 for practical project management information. All rights reserved.