Information-Management Podcasts


< Back

The New and Improved Technical Support: Part 1
December 19, 2008 12:00 PM

By Randy Miller
Randy Miller
Director of Services

I have two hats hanging on the wall of my office.  The first is labeled "Professional Services Manager" and the other is labeled ‘Technical Support Manager.'  I have managed the tech support team at a software company for about seven years now.  

My 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.  They said that they were tired of getting yelled at by customers, and they were tired of seeing salespeople doing support instead of selling.

When I inherited the team, we were hemorrhaging angry customers; now we haven't received a legitimate customer complaint in years.  Despite fumbling and failing for a while, I was able to create a winning plan for reinventing technical support.  In this series of articles I will help you learn from my mistakes and implement measures that will make your team a success.

What's Wrong with Support?
The technical support industry has always been in a death-spiral.  It is a self-fulfilling prophecy dating back to when telephones were installed in every home.  Everyone views it as a dead-end job, so you can only hire people who can't get jobs doing anything else.  These people don't really care about the position, eventually get tired of all of the customer complaints, and move on quickly. 

As you lose staff members who were not high quality to begin with, you find that any attempt to improve is soon thwarted.  Everyone outside of the team blames your department for customer complaints.  No one thinks it can be fixed, so you can't get budget to fix it.  Sound familiar?  

Technical support can be fixed.  Not only that, but you can start getting genuine praise for your team's helpfulness and hard work.  Follow-on sales and referrals will increase.

How Do We Do It?
Technical support is a team process.  Like a team of jugglers, you will need to know how to catch the bowling balls, flaming batons and knives.  This takes department-wide communication and making sure that everyone is on the same page.

1.    Prioritize - The very first thing that you have to work out is how you are going to prioritize incoming cases.  What constitutes an urgent case?  What constitutes a case that you can get around to next week?

Create 3-5 categories of case severity and decide on some service levels for each-how quickly you will respond and how quickly you will fix.  There is probably a set of priorities in your maintenance contracts already, and if there is, don't bother reinventing that wheel unless it is utterly unworkable.  Even if they are slightly beyond your abilities today, you can choose to accept them and move forward.

Once you make these decisions, talk them through with your team.  They all need to understand that the top priority cases must be addressed first.  Someone must pay attention to all incoming cases, and when they deal with one, they must prioritize it immediately.  This requires someone to pay attention to the incoming cases.  Everyone on the team should also know who the backup will be.

2.    Document Solutions - Technical support is all about time.  New cases appear, as if by magic, while you are still working on your current case.  The longer your current case takes, the more new cases appear.  

So what is the fastest way to resolve a case?  Fix the problem so that the customer never sees it.  If you can't do that, the second fastest way 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, so 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, we built a knowledgebase.  This took time, but the rate of return was fantastic.  Our first knowledgebase was a big text document on a shared network drive.  We had about a hundred problems and solutions in that text document until we were able to implement real helpdesk software that had a knowledgebase feature.  

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

3.    Fix It Yourself - If you are a software company, then you need developers within your technical support team.  Beg, borrow, or steal, this is the biggest game-changer available.

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, creative code when they have to stop and fix a bug for you.  You ask for a low-level design change and they give you back a better error message.  

When you have your own developer, you suddenly start getting those low-level design changes, as well as other useful tools.  A developer who is focused exclusively on fixing bugs will do things that an interrupted developer would never do.  (I call that thing "fixing it right.")  They will even find and fix things you didn't know were broken!  Bottom line: I will never again manage a technical support team without at least one full-time developer.  

A New Attitude
You will need to inspire a new attitude within the team in order to make the changes you want.  You can't do it all at once, so put up posters and talk to your team.  Praise and reward your people when you hear them picking up the new attitudes such as "I am responsible for getting this fixed" and "I won't take a customer's anger personally."

One of the turning points in the rebuilding of my technical support team came when I fielded a call from an angry customer whose software was completely down.  I don't remember what he had done to his server, but his colleagues were yelling at him.  He called in and was abusive to one of my people, so I took the call and attempted to calm him down.  

The customer was totally out of control.  I apologized for the problem.  He yelled and cursed at me.  I stopped talking until he stopped, and then I said in a very even tone, "I understand why you are frustrated.  I want to help you.  But if you continue to curse at me, I will hang up on you."  He cursed.  I hung up.

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

After that my team all stood up a little straighter.  We were professionals, and we would insist on being treated professionally.  Our pride in our work increased, as did the quality of our work.  That story has been retold many times to new team members, and the attitude of professionalism has been caught.  

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

Understanding your current state is essential in order to show progress and improvements from your efforts.   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 get to the executive team each week?

Short-term goals will allow you to get the revolution started.  These include:
  • Gaining approval to proceed with reinventing the technical support team.
  • Choosing new tools and putting them in place.
Medium-term goals should involve getting support under control.  These include:
  • Handling all tech support calls within the team.
  • Escalating calls internally and getting problems resolved before customers get angry.
Finally, long-term goals should be focused on ongoing improvement.  These include:
  • Understanding and reducing support costs per product line and product launch.
  • Understanding and reducing support costs per customer and customer attribute (e.g. market, size, industry).
Understanding 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 to yield profit information.  You will find that your profit is lumpy and uneven because some types of customers are more expensive to support.  

Over the long term you need to present that data back to senior management so that they can make profit-maximizing decisions about pricing and product direction.

Measurements and Metrics
After defining your goals, it will be important to measure all of their components as well as your support workload in order to know when you need more staff.  

Implement a helpdesk tool that will give you 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.

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

Now unless something very strange happens-a massive number of customers defect to a competitor, for example, or your development team gets replaced with zombies that write perfect code-your number of support cases is going to increase over time.  More customers and features lead to more complexity.  That is a trend you need to watch closely.

The other trend that you need to watch is that your team will get better and better at resolving cases faster and faster, so you will be able to handle more cases next month than you did last month.  Plot both trends on a graph and update it every month.  

This data will allow you to see, for example, how 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 use that data to predict support bottlenecks weeks before they occur.  If you can predict it, you can be prepared for it.  Hire some temps a few weeks before the next release.  Make sure that none of your key team members are taking vacation during the crucial weeks after a new release.

When you see that the long-term trend lines are about to cross, you need to hire more staff or make some paradigm-shifting breakthrough to improve your time per case.  Hiring is easier, and Part 2, of this series will guide you through the process.

Randy Miller
Director of Services

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 and can be reached at

About Us Subscribe Editorial Register

© 2014 Simplex Knowledge Company. All Rights Reserved.   |   TERMS OF USE  |   PRIVACY POLICY