May 31, 2006 5 min read

Crowding Out Tech Support

Crowding Out Tech Support
Photo by Steve Ding / Unsplash

This week, there’s been a lot of discussion in the blogosphere and popular press about “crowdsourcing” — empowering crowds of amateurs to do tasks previously filled by professionals. (See Jeff Howe’s Wired story.) The next trendy opportunity for startups to offload parts of themselves onto the market.

Tech Support (aka Customer Support) is on many executives’ lists of outsource-able functions. I’ve been talking with Tech Support teams at several startups, however, and see real value in a dedicated team that helps customers love you. Here’s my contrarian view on getting more out of support teams.

First, some background

Tech Support (Customer Support) is the group of live humans helping customers and prospects in active phone and email conversations. They also own online vehicles for customer self-service: FAQs, chat and support blogs. More than any other group, Support serves customers who have already paid money for your products – and whose repeat business is critical to next year’s revenue.

Often, though, I see Tech Support ignored, under-equipped, and stuffed into an organizational closet. A cost center, a necessary evil, tasked with answering calls as quickly as possible. New product training is an afterthought, metrics are missing, and promotion into better-paying positions is rare. A perfect opportunity for outsourcing, offshoring or crowdsourcing.

This approach is built on hidden assumptions that [1] our products are perfect, [2] all customers will support themselves online, and [3] customers will still happily recommend our products even if we treat them badly. Wrong on all counts.

In my experience, making Support a strategic asset takes a combination of organizational planning, good tools, and product management thinking. Let’s grapple with each in turn…

An Organizational Home

Tech Support usually reports up through Engineering. Unfortunately, a lot of what Support requests sound to engineers like criticism: “our customers are having trouble installing the new graphics application” or “the UI is confusing.” Engineering has plenty to fix without new problems from Support, so naturally ignores what it can. (Ask someone in QA what reaction she gets when filing new bug reports.)

Another approach is to move Support into the Sales organization. This tends to co-opt Support into a tele-selling role, pushing service contract renewals and paid upgrades, when they should be concentrating on understanding and pacifying upset customers.

I’ve seen some good alternatives: Splunk has rolled Support under Product Management, so that fresh customer input flows right into PM. Cemaphore has Tech Support included in a broader Operations group alongside IT, and has Support do product acceptance testing. Regardless of its location, Tech Support needs some executive help to avoid obscurity.

Tools of the Trade

Once the team has a home, don’t forget some basic tools. Like the shoemaker’s barefoot children, Tech Support teams at tech companies often lack necessities:

  • Customer information. You don’t need a fancy CRM system. In fact, new research suggests that customers really want to talk with engaged and empowered employees who can actually address problems… which CRM systems can undermine. Double points if you can tell whose support contract needs renewal.
  • A case tracking system. Not to be confused with CRM systems, these capture details about customers and problems. A good Case Tracking System can help you identify trends, patterns and root causes of issues. FYI, PostIt© notes are not a good substitute.
  • A few regular metrics. Once you’re tracking each case, start with weekly reporting of case loads, portion of cases closed on the first call, and which products generate the most problems. Don’t be seduced into giving bonuses for “fewest minutes spent per customer.”
  • Lots of bite-sized product training. The best Tech Support reps are empathetic and enjoy interacting with customers. If they “give good phone,” they are probably bad at sitting still for extended classroom training. Explore product training that takes advantage of multiple media, unplanned down time, or lunch-and-learns for bite-sized product updates.

All of this seems obvious, yet many companies go without. They’ve failed to find an organizational champion and a systematic view of customer support. Along the way, they’ve failed to pull corporate-wide value from Tech Support.

Here’s where some classic product management skills apply: how do we think about Support as a way to improve the company’s products and position in the marketplace? Where can we gain advantage from the Support organization we’ve already paid for?

Thinking like a Product Guy

Support folks tend to be technical, straightforward, and heads-down. Few understand the non-technical challenges of product planning, and fewer have spent much time with Product Managers. Injecting a little product thinking can yield some great results.

Imagine, then, a monthly sit-down with product management and technical support, where both teams grapple with the “top ten” support list. Starting with reports of actual case loads, everyone can learn by sorting issues into distinct categories.

Note that the way we propose to fix a problem depends on the category we assign it to: communications problems are solved by communicating better; software problems are fixed with new releases. Putting problems in the wrong bucket leads to wrong-headed solutions.

Here’s an assortment from a recent Support/Product Mgmt triage session:

  • Customers Can’t Find the Answer. For instance, just after you ship a new software version, you should expect lots of “what’s your upgrade policy” inquiries. Before the next launch, consider putting the upgrade policy at the top of your FAQ page and in the customer newsletter and on your home page and in email blasts to licensees.
There are known unknowns…
  • Customers Can’t Find the Feature. When users have trouble locating a menu item or function that’s already in your product, you probably have a UI or naming problem. For instance, if Tech Support is constantly telling customers that your version of Mail Merge is called “Customized Letter Generator,” then perhaps you should change its name. And list it under the Tools menu. And cross-index both names in your help files.
  • Our software crashes. A bug. Get it fixed. No excuses.
  • Positioning a Non-Feature. The product team may already have decided not to include a requested feature. Tech Support needs help explaining this. Spend some time on why a feature won’t be included, and how Support should talk about this to customers, with answers like “Here’s an easier way to do the same thing…” and “Some good third party products that work well in this situation are…” and “We’ve had some other customers raise concerns about this feature because…”
  • Policy issues, such as who gets free upgrades, are the toughest for Tech Support—callers always have excuses for breaking your company’s rules. Set some reasonable rules with minimal red tape. (“If anyone from our top 50 customers calls and has a valid email address at that company, give them all of the help they need. The account manager will clean up any billing issues after the crisis is over.”)

And so on. Figuring out what kind of problem you have is the toughest part of solving it. Together, Support and Product Management can improve products and customer experience.

SoundBytes

Tech Support sounds like something your company should outsource or “crowdsource,” but you may instead drive off your customers. Get Support the organizational and strategic help it needs to capture real customer value.

Great! You’ve successfully signed up.
Welcome back! You've successfully signed in.
You've successfully subscribed to Rich Mironov's Product Bytes.
Your link has expired.
Success! Check your email for magic link to sign-in.
Success! Your billing info has been updated.
Your billing was not updated.