I have been the technical support manager at Journyx, a timesheet software company, for seven years. When I inherited the team, we had many angry customers. We haven’t received a legitimate customer complaint in years. It took a lot of hard work and a few failures to get here however.

 

My training and experience was originally in sales and retail management. So when I became manager of the technical support team, I asked the CEO and vice president of Sales what they wanted to achieve. They had two answers for me: they were tired of getting yelled at by customers for lousy support, and they were tired of seeing salespeople waste their time doing support when they should br selling. It took me a few months to find a winning strategy and a year to implement it effectively. Before I outline how to execute that strategy, however, consider what your technical support team looks like.

 

Why Redesign in the First Place?

 

The technical support industry gets a bad rap. People view technical support as a dead-end job and very few are interested in spending time listening to people complain. This leads to a staffing problem for managers, who are consequently forced to hire people who can’t get jobs doing anything else. They are employees that don’t care about their work and eventually quit.

 

It is hard to improve a department with such unmotivated staff. Everyone blames technical support for customer complaints, and if no one believes that it can be fixed, good luck getting budget to fix it.

 

How Do We Do It?

 

Organize Priorities

 

The first step to redesigning a technical support team is deciding how to triage incoming cases. Outline a few categories of case severity and list service levels (i.e., how quickly you will fix such cases). If you already have priorities listed in your maintenance contracts, use those. It will save time and work.

 

Once these decisions are made, talk them through with your team. Everyone must agree on a few crucial areas. Top priority cases must be addressed first. Someone must be responsible for incoming cases and prioritize them immediately. There must be a backup for this person, and everyone on the team has to know who that is.

 

Document Solutions

 

Technical support is all about time. New cases appear, as if by magic, while working on a different cases. You can get ahead of the curve by saving time. Every minute saved on a current case compounds, because you can get into and out of the next case that much sooner.

 

The fastest way to resolve a case, aside from fixing it so that the customer doesn’t see it, is to publish the solution and let customers solve the problem for themselves. Writing up a generic solution allows you to send it to each customer - adding details applicable for the situation at hand. This is important, so make it a habit. Every time you resolve an issue that you haven’t seen before document the problem and solution while all of the details are fresh in your head. Make sure that the steps are clear and concise.

 

The first five to ten times that you send the solution to someone, double-check that the instructions are general enough to suit each customer. If they are not, edit the document. This makes better “copy-and-paste” templates for public publishing.

 

If your management will allow it, publishing the problems and solutions on a public knowledgebase is extremely beneficial. Customers will be able to help themselves, giving you more time to work on other things. You can always gate the knowledgebase to allow access to paying customers only.

 

Fix It Yourself

 

Having a developer on your team is another important step to reinventing technical support. You will not be able to attract a developer unless you have a fairly professional organization; so get some successes under your belt and swagger in your step before you try to hire one.

 

Imagine what goes on in an organization without a developer to call your own. You punt a bug to the development team for patches, interrupting them. You ask for a low-level design change to keep customers from getting themselves into a broken state. The result is a better error message, you say bad words and stick another needle in the voodoo doll. (I’ve asked around. All support managers have developer voodoo dolls.)

 

Having your own developer will provide the low-level design changes you ask for. A developer will provide new investigation tools and fix your bugs. Not only that, they will find and fix things you didn’t even know were broken. I will never again manage a technical support team without at least one full-time developer.

 

Success

 

When your support developer starts working his/her magic, the number of bugs that customers experience will go down. This could lead to customers who drop their maintenance contracts, feeling that they do not need support. If this occurs, look at your financial model and figure out what other things you can include in your maintenance package. (This is a great problem to have!)

 

The New Outlook

 

You will need to help your team embrace a new attitude to make the changes you want. Here are some integral parts of that new outlook:

 

  • I am responsible for getting this fixed and getting the problem/solution documented so no one has to troubleshoot this problem in the future.
  • I understand that people are frustrated and angry. They aren’t angry at me. I won’t take it personally.
  • The more upset the customer is, the more I need to calm them down.
  • I will not accept abuse.

Put up posters. Talk to them about these new attitudes. Praise and reward them when you hear them picking up the new attitudes.

 

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.

 

One of the turning points in rebuilding my technical support team came when I fielded a call from an angry customer. I don’t remember the specific details, but he broke our software and his colleagues were yelling at him. He called in and was abusive to a team member, 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 called his company back to ask if there was someone else 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. We weren’t just whipping posts anymore. We were professionals and insisted on being treated as such. Our pride in our work increased, as did its quality. That story has been retold many times to new team members. The contagious attitude of professionalism was caught.

 

Setting Goals and Measuring Progress

 

It is important to gauge where technical support is and effectively set short-, medium-, and long-term goals for improvement. How many cases does technical support deal with on a weekly basis? What about other departments? How many customer complaints reach the executive team? Knowing this allows you to look ahead and decide what you are shooting for.

 

Short-term goals are necessary to jumpstart your reinvention process. Start with getting permission to reinvent the support team. Then, choose which tools to use and being putting them in place.

 

The next step is setting medium-term goals that will get support under control. These include handling all technical support calls within the team and getting problems resolved before customers become angry.

 

Long-term goals are intended to encourage and enhance ongoing improvement. Understanding and reducing support costs per product line, product launch, customer and customer attribute (e.g., market, size, industry, salesperson, title of primary contact, etc.) is an example. Understanding your cost per customer attribute is especially important because this data, when paired with income per customer data, yields profit information. This, in turn, shows which types of customers are expensive to support, and management can base important decisions on this information.

 

Measuring achievements against goals is simpler than you think. Implement a helpdesk tool that will provide reports on how many cases are opened and closed per day, week and month, how much time is spent on each case and aggregate cases per customer. More advanced goals require more advanced reports. You can obtain these by connecting your helpdesk to your customer relationship management (CRM) and/or accounting system, duplicating CRM and accounting system data in your helpdesk or merging CRM and accounting system report data with helpdesk report data. You should also be measuring the technical support workload in order to know when additional staff is needed.

Register or login for access to this item and much more

All Information Management content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access