Reinventing Tech Support
Randy Miller
May 19, 2008
Many organizations view technical support as a cost that must be borne and little else. It receives
very low budget priority and is a perpetual source of customer complaints. But a well managed
reorganization of the technical support department can turn it into a valuable customer retention
tool. Here’s how one company did just that.
One of the largest and most significant projects I have ever had to undertake was
redesigning my technical support team. I have managed this team for seven years, and
when I first began, we were hemorrhaging angry customers. As my training and experience
was not in this area, I asked both the CEO and Vice President of Sales what they wanted me
to achieve. One of them said, “I’m tired of getting yelled at by customers for lousy support.”
The other said, “I’m tired of seeing salespeople do technical support instead of selling.”
With that, I was able to craft a winning plan. In retrospect, I can see things that should
have been done sooner as well as things that shouldn’t have been done, and with this
knowledge, I will outline the plan and give practical advice on how to put it into action.
So what is wrong with support in the first place? First of all, it is incredibly difficult to hire
quality staff. Everyone views tech support as a dead-end job, and no one wants to listen to
people complain for a living. Such low staff quality and motivation, in turn, undermines any
attempt to improve. Everyone else in the company blames technical support for all
customer complaints. No one believes that it can be fixed, so you can’t get any budget to fix
it. Sound familiar?
The complaints can end, and your team can start getting credit for its hard work. Follow-on
sales and referrals are not far behind, but redesigning your team is necessary to achieve it.
Step 1: Planning
Technical support is like a team of jugglers, and a decent amount of planning and team-
wide communication is needed in order to do it successfully.
Triage
The first plan you need to make is how to triage incoming cases. You will have to determine
what will constitute an urgent case and what will not. It’s best to formulate 3-5 categories
of severity and decide on service levels for each — how quickly you intend to respond and
how quickly you will fix. (You may already have a set of priorities in your maintenance
contracts, which will make this a lot easier.)
Discuss the plan with your team and make sure they understand that top priority cases
must be addressed first, someone must pay attention to incoming cases, and the first
person to deal with one must prioritize it right away.
Document Solutions
The fastest way to resolve a case is to fix the problem so that the customer never sees it. If
you can’t do that, the second best way is to publish the fix and let customers solve the
problem themselves. If you don’t have the time to provide all of the necessary technical
details, you can write up a rough version of the solution and copy-and-paste.
At my company, we built a knowledgebase that has proved infinitely valuable. Our first one
was a text document on a shared network drive containing about 100-plus problems and
solutions. Later on we implemented real helpdesk software that contained a knowledgebase
feature.
If you haven’t been doing this, you must start now. If you have been lax, redouble your
efforts. Every time you resolve an issue that you haven’t seen before, stop and document
the problem and solution. Do it while all of the details are fresh in your head and you still
have all of the test sites in front of you. When you copy-and-paste that answer out to
someone, double-check that the instructions are general enough to suit the customer. If
not, then edit the original document and improve it. This process will help you develop
better copy-and-paste templates.
If management allows it, publish the problems and solutions in a public knowledgebase so
customers can help themselves. You can always gate the knowledgebase to only allow
access to paying customers, but get that documentation into your customers’ hands.
Fix It Yourself
If you are a software company, you need developers within your technical support team so
you can stop punting bugs to the development team for patches. When developers have to
stop and fix a bug for you while they are trying to work on their own fun code, you may run
into a problem. For example, you ask for a low-level design change to keep customers from
getting themselves into this broken state, but they give you a better error message.
When you have your own developer, you will get your low-level design changes, as well as
many other useful 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 Gotcha
Having a developer on your team means the number of bugs that customers experience will
start to drop. You might have customers who choose to discontinue their annual
maintenance contracts because they feel they don’t need support anymore. If this happens,
you will have to look at your financial model and consider adding other things to your
maintenance package.
Step 2: Buy-In
You will need to help your team embrace a new attitude in order to make the changes you
want. Here are some key values that they should hold:
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. I won’t take their anger
personally.
The more upset the customer is, the more I need to use calm words to help the
customer calm down.
I will not accept abuse from customers.
It is often best to teach by example. Answer some support calls in front of the team, or tell
them stories over lunch about how you handled a certain situation by taking responsibility.
Attitude is contagious, and they have to catch it from you.
Step 3: Setting Goals and Measuring Progress
Overhauling your technical support team is a large task, and it cannot be done without first
discerning your current state and setting goals for improvement.
Current State
Understanding your current state is essential in order to show progress and improvements
from your efforts. Ask yourself how many cases the tech support team receives each week,
and how many cases other departments handle each week. Finally, think about how many
customer complaints reach the executive team each week.
Here are some potential short-term goals:
Gaining approval to reinvent the technical support team.
Choosing your new tools and putting them in place.
Medium-term goals may include:
Handling all tech support calls within the team.
Escalating calls internally and getting problems resolved before customers get angry.
Focus on ongoing improvement through the following long-term goals:
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, salesperson, title of primary contact, etc.).
If you combine the customer data with data on income per customer, you will soon find that
your profit is uneven because some customers are more expensive to support. It can also
help senior management make better decisions about pricing and product direction in the
future. For example, they might chase more profitable markets at the expense of less
profitable ones, or increase their prices to less profitable markets.
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 more staff. You should aim to implement
a helpdesk tool that will yield reports on the number of cases opened and closed per day,
week, and month, the amount of time spent on each case, and the aggregate cases per
customer.
For more advanced goals, you should 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
Your number of cases is almost certainly going to increase over time, as more customers
and features leads to more complexity. Your team should also be getting better at resolving
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 you can plot them in terms of
minutes per day.
Graphs like this will help you to be prepared for future support bottlenecks. For example, a
new release may temporarily increase your caseload and decreases the number of cases
you can handle (as your staff learns the new version). If you can predict this in advance,
you can hire some temps a few weeks before the next release.
When you notice that the long-term trend lines are about to cross, you will need to hire
more staff. Try to find people who fit into your new support team framework in terms of
attitude, dedication and competence.
The project of reorganizing your technical support team doesn’t have to be as difficult as it
seems. If you take each step in stride, you will be well on your way towards happier
customers and respect throughout your company.
Randy Miller has held many different positions at Journyx since joining the company in
1999, including sales engineer, trainer, consultant, product manager, support team
manager and implementation manager for Enterprise Accounts. Randy has 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. He
can be reached at randy@journyx.com.
The URL for this article is:
http://www.projectsatwork.com/article.cfm?ID=242778