Posted on
by

I previously wrote about how the traditional shallow Pareto of customer support issues is no longer a useful approach to mitigate support calls. The surprising news is that most companies have created this situation for themselves. There are two primary ways that companies do this.

1. Long term focus on top issues Pareto: When a company has a long term policy of addressing the top support issues, then over time the top issues get smaller, while the smaller issues increase in quantity. The few top issues are either eliminated – taking them off the Pareto entirely, or reduced, shifting them lower in the Pareto. Doing this again and again yields a situation in which the top issues are continuallyeliminated while very little happens with the small issues. These small issues then are responsible for the vast majority of calls.

2. Proliferation of products: A large company with diversified businesses, such as an consumer electronics company or computer manufacturer may have many product lines, with each product line having many products. With hundreds of products, each product itself having hundreds of issues, it is likely for the company to be faced with tens of thousands of issues. In many cases companies may needlessly worsen the situation. For example, derivative products created to ensure different SKUs for different channels may artificially inflate the number of customer issues because issues are tracked by product. In other cases, companies may release very minor updates to refresh product lines for seasonal events – these updates may each have their own issues. (Conversely, the frequent updates associated with agile development for web services do not create a proliferation of different products, because the “older” product is essentially retired with each update of the web site; there is only one product, and it is the most up to date, fresh one.)

Consumers realize that companies pick and choose the issues they will address. A common refrain among research participants is “manufacturers have frequently asked questions on their websites, but I need the infrequently asked questions.” Companies need a customer support strategy that address the long tail. Not surprisingly, social media will have a substantial role to play, but that alone is not sufficient to address a long tail situation. In my next post on this topic, I’ll go into the three key forces identified by Chris Anderson in The Long Tail, and discuss how those forces apply to customer support.

Posted on
by

Via Leslie Katz at CNET comes news that Best Buy and Fixya are working together on co-branded Support 2.0:

Those who prefer getting help from peers over negotiating the sometimes headache-inducing labyrinth of traditional tech support will have an additional online outlet come Tuesday. FixYa, a user-generated Web site for product care support, is set to announce a co-branded effort that brings Best Buy customers and the Geek Squad together to swap real-world solutions to common technical problems. Think social networking meets tech support.

Customers wanting to perform their own fixes (or trying to dig others out of trouble) can go to the Best Buy Web site and access http://geeksquad.fixya.com from the “Customer Service” tab. They can search by product, SKU, manufacturer, or product category, or post a new query and receive community troubleshooting.

The announcement also stated that Fixya now has more than 30,000 contributors.

Posted on
by
In 2000, I was part of a team developing web applications. We favored open source software for the foundation of our web services, such as Apache and Linux, and widely used software such as BEA Weblogic, and the Java programming language.
Using these tools, when we ran into a problem, we could count on being able to Google the problem, and find an answer – usually within a few minutes. Sometimes the solution would be posted by another user like us who encountered the same problem and worked out a solution. On other occasions, the solution would be posted by someone from Weblogic or Apache, who would be monitoring public forums for problems posed by users, and would answer with the expertise of someone intimately familiar with the product. On the rare occasion when we couldn’t find an answer, one of us might post our problem to a relevant Usenet newsgroup. Within a few hours, we’d get a helpful response from someone else who ran into the same problem and figured out how to solve it.
Our team worked at web speeds, we were passionate and dedicated, and we loved our work. Being “in the flow” was a big part of it: you get going, you are productive, you feel productive, and it makes you even more productive.
Then, in 2001, for reasons quite unconnected to anything our little team was doing, our company forced all Java web application teams to move to a single proprietary J2EE platform. The support model changed to a typical enterprise support model. We funneled our support requests to a single support contact, they funneled our requests to the support team for the priorietary software, then the requests would get funneled to the right support or technical experience.
The pace of everything slowed dramatically. The questions we used to research and answer ourselves via a simple Google search in five minutes now took at least 24 hours to turn around. And the more technical stuff that we use to get answered via a Usenet newsgroup or web forum now could take a week or more before we got a response.
Meanwhile, productive work would grind to a halt. For engineers who were used to working on Internet time, and getting an answer commonly within 10 minutes, and in the worst case within several hours, this was the ultimate frustration. The team grew dissatisfied, productivity plummeted, and we were no longer “in the flow”. Even when their customer support finally did get around to answering our questions, no one else could benefit from it, because the problem and solution were never posted in a public forum.
The worst part of all this is that the “support” of the proprietary J2EE software was considered one of the benefits of using it by the management folks who made the decision to use it. But free, open support is far superior to paid, closed support. This is something that open source developers and users have known for years, and it is a big part of the reason why open source software has such a passionate and loyal following.
There are several lessons to take from this story:
  1. Knowledge capture and public sharing improves the support experience and decreases the work required by paid support staff.
  2. Customers inherently have a customer perspective on issues, which paid support staff lack.
  3. For a popular product, there are likely to be more customers available for helping other customers than there are support agents available.
  4. In most cases, the speed and access advantages associated with abundant information on the web far outweigh any minor benefit to be gained from one on one paid support.

Posted on
by

Furqan Nazeeri on how Support 2.0 not only avoids support calls, but creates more loyal customers:

Then along comes support 2.0. Not only is it far better, but it is much less expensive. A great example of what I mean by support 2.0 is NVIDIA, makers of high end video cards for computers. NVIDIA hosts a very popular discussion forum as part of their support service. If you read the posts, there are many and the beauty of this is that customers have a “living FAQ” that addresses many more topics than standard ones could ever do and you will also see that many of the “answers” come from evangelist customers!

Posted on
by

When deciding what customer issues to focus attention on, most companies naturally choose their biggest, most important issues first. Usually using the number of support calls or warranty cost as the criteria for ranking, they will focus on the few issues that account for the bulk of their support. 
The success of this approach relies on the 80/20 or Pareto rule: the idea that 20% of customer issues will account for 80% of the cost. Most people with business experience know the rule is applicable in many situations: the top 20% of customers account for 80% of sales, 20% of the steps in a project will account for 80% of the work, 20% of the products on the shelf account for 80% of revenue, and so on. And in many cases, the distribution is sharper than 80/20: it can be 90/10 or even 95/5 just as easily.
When customer support issues have this kind of a ratio, it is very easy to decide what to do. The traditional top issues approach says that a company should focus on addressing critical few issues: pick the top five or ten issues, and then focus all effort to resolve those underlying issues: improve the product, improve the help, add online help, or create a frequently asked questions list.
But over time, this approach has become less effective for a variety of reasons. Today, many large companies will find that it is uncommon for any single customer issue to be responsible for more than 1% of calls or support cost. Therefore, even a massive effort to address the ten largest support issues would result in a less than 10% reduction in support calls. Since the traditional top issues approach to addressing issues usually relies on a relatively large investment per issue addressed, it’s not possible to simply take the existing methods of addressing issues and extend them arbitrarily deep into the prioritized list of issues. 
A new approach is needed.
Although I won’t get into the details of this approach in this post, here are a few hints: We will draw inspiration from a parallel in product sales called The Long Tail. Chris Anderson first drew attention to the concept with an article in Wired magazine, and then later a best selling and influential book. Chris Anderson analyzes how three key forces enable sales of even minor products, in aggregate, to outsell blockbuster products. We’ll apply those same three forces to customer support. And no surprise: we’ll end up squarely in the realm of Support 2.0.

Posted on
by

I believe than some companies tend to have a mismatch for each of their support channels between the needs of the customers who prefer that channel, and the support actually delivered by that channel.

For example, some companies:

  • Provide the only the most basic, frequently asked questions via their website (the eSupport Channel)
  • Use the least skilled support agents for live chat support
  • Use the most skilled support agents for phone support

Why do companies make these choices? Well, online support content can get messy for complex issues, and it’s tough for a company with limited internal to generate all the long tail support content they would need to tackle every issue that customers face.

And when it comes to chat versus phone, companies can sometimes get away with less-well paid agents for chat support because the company does not have to pay a premium for good verbal English skills (written English skills are less demanding). Of course, those good verbal English skills may frequently correlate with higher overall agent effectiveness and communication skills. So in effect, the chat agents may be less effective than the phone agents. Of course, companies can validate this for themselves: how does your resolution rate compare between chat and phone?

So why is all of this problematic? Look at the profile for two segments of customers:

Techie customers:

  • Solve basic issues themselves using simple troubleshooting skills they innately possess
  • Need online support for advanced issues
  • Strongly prefer email or chat support if they must get human assistance

Non-technical customers:

  • Need help solving basic issues
  • Strongly prefer calling if when they must contact the company
  • Avoid online self-support and online chat/email support

What we end up with is a mismatch between the customer needs and the support channels:

Technie customers:

  • Need advanced help online, but can’t find it there.
  • They end up with the perception that companies never have the help they need. (because they don’t need the help that companies provide online.)
  • When they result to human support (chat/email), they get bad assistance which confirms the fact that companies are clueless.

Non-techie customers

  • Need the most basic help and end up with the most knowledgeable and expensive agents who end up spending hours working one on one to walk a customer through the process of installing software from a CDROM.

There are some simplifications here. But at the root of it all, there is definitely a mismatch. Because of this mismatch, companies over-invest in support for customers who need more basic help (wasting resources), while under-investing in support for customers who need more advanced help (leaving dissatisfied customers).

Posted on
by

Previously I posted about the rise of support activism and negative word of mouth. There are a several things a company can do to mitigate the risks of support activism and negative word of mouth.

Improve the Product Quality

In the past, all those inconveniences that didn’t actually raise warranty costs (because they didn’t result in a support call), even if they affected the user experience, got ignored by companies. That has to change. Not only does product quality simply need to improve across the board, but the prioritization criteria of customer issues has to change as well. What is most important to fix is what your customers say is most important to fix. And that is not necessarily the same as what causes your customers to call.
Here’s an example from the old days of VHS players: If a customer’s VHS player couldn’t play tapes, that would generate a support phone call or a product return. But if a customer’s VHS player was too hard to program and sat blinking 12:00 all day, they might not call support or return it. They might just live with blinking lights flashing at them all day long, creating a lingering dissatisfier.
People view support calls as an absolute last resort. And since the correct time and the ability to record programs on a timer isn’t crucial, they’ll live without those capabilities. They’ll live without them, but they’ll always be pissed: “I bought product X, and it just doesn’t work.”
Similarly, what is most satisfying about a product may not be what is most important about it. It is most important that my car start when I need to use it, but the six speed manual transmission is what is most satisfying about it. (These are the kind of subtle nuances you’ll learn about reading automotive forums on the web, but which are hard to uncover in traditional customer research.)

Address Support Issues Where They Arise

If a product issue shows up on a blog, in most cases, the best approach is to post a comment on that blog as a response, explaining how to address the issue. You will instantly convert the negative customer experience into an overwhelmingly positive support experience: “Wow, the company found my blog and cared enough about me to post a response for how to fix the problem.” They will tell that story to everyone they talk to that day or week, and any time your company comes up in conversation, they’ll relate that story. You’ll be the company that cares enough to go out and find problems. Here’s a secret: this is what is already happening in the open source movement, and it’s a major reason why open source users and developers are so passionate about open source. The developers and maintainers of a project are not just suppliers of technology, but participants in the community that surrounds them. So they are active on blogs, and discussion forums, and in wikis. And when they see someone having a problem, they step in.

Addressing Issues Where They Arise To Defuse Viral Explosions

The second thing that happens when you address support issues where they arise is that you instantly defuse the viral explosion of the original negative experience: before the original complaint can make it around the blogosphere, your very visible assistance and resolution of the problem, right there alongside the original post, will completely change the nature of what is being shared. It’s no long a bit of sensationalism or inflammatory material, instead it is just a problem and a resolution. It’s not very sexy, and it won’t get shared nearly as widely as the negative-only experience would have.

Alternatives to addressing it this way are far less effective

The alternative methods to address a bad experience shared via the blogosphere are far less effective. A customer shares a bad experience, and the company takes one of these alternative actions:

  1. Contacts the customer directly via email to share a resolution to the problem.
  2. Carefully considers the problem, consults the Legal department, PR department, crafts a response, runs the response by Legal and PR, and then posts the response, but only after 2,000 people have seen and linked to the original issue.
  3. Takes the posting of the issue as a call to action to get the issue resolved in the product, or to get better documentation on the companies web site.

All of these alternatives are better than no action at all, but they miss the biggest opportunities: to give support in a visible way that helps not just the original people who had the issue, but also everyone else who was searching for an answer to the same problem and saw the the issue after it was posted, and to defuse any negative viral explosion that occurs from the original posting. It’s like fighting a forest fire: a bucket of water applied early on in exactly the right place can put out a smoldering campfire. The same bucket of water will have no material effect when the fire is an acre in size or when it isn’t put right on the fire.

But if posting on the blog isn’t an option because the legal department or PR department have previously rules against that kind of activity, the next best course of action is usually to email the customer directly, because this can be done the quickest. The customer may post about it the positive experience, which is a bonus.
Posting on small blogs vs. posting on product review sites
All of this holds true for product review sites as well as blogs, with one crucial difference. When a big company takes the time to post on a small blog, most people will interpret the action as really caring about the customer. When a big company posts on a product review site used by millions of people, most of those people will interpret the action as self-serving: the company is just there to defend themselves. In Web 2.0 research, people reported that one of the reasons they distrust company websites is because the information is biased: the company only ever describes their own products in glowing terms (as opposed to the more neutral treatment they would get by someone without a vested interest on a product review site, discussion forum, Wikipedia, etc.). This means that small, authentic companies can probably post on a product review site and get taken at face value, but a big corporation needs to really build credibility in the social media space before their post on a product review site will be acceptable.

I’d like to hear your thoughts on this topic.

Posted on
by

In 2007 I frequently checked the blogosphere for “Support 2.0”, “Collaborative Support” and similar terms and found very few posts. Although much of the discussion around social media encompasses technical and customer support use cases, few of it focuses specifically on that domain. And where support was discussed, it was most frequently only in the context of discussion forums. This year I’ve noticed a few more folks specifically talking about support, and taking it to the next step of blogs and wikis. Here’s a few relevant posts:

Posted on
by

Josh Bernoff, of Forrester Research and coauthor of Groundswell, and Joe Cothrel, VP of Community at Lithium Technologies have a very worthwhile webinar, Join the Groundswell in Enterprise Social Software, available on-demand. Both speakers were worthwhile, and I took four full typed pages of notes while listening to the original broadcast. A few highlights:

  • Josh Bernoff told a story of about Linksys: it was Christmas day, normally one of the highest call volume days of the year as customers unbox their new wireless routers. But there was an earthquake in India that blocked the telephone lines, so no customer support was available by phone at all. It could have turned out to be a customer service disaster. But LinkSys had community support forums online, and customers were directed to the forums for support. So on Christmas day, every customer that needed help went to forums to get their questions answered, and LinkSys did not see customer complaints about the lack of available phone software.
  • Joe Cothrel said that Lithium has seen that you need on the order of mid-thousands of customers sent to a online community for that community to flourish and become self-sustaining. You can start in the hundreds or low-thousands, but it is a very different situation. But in mid-thousands, then a community can drive itself.
  • Josh, speaking on the importance of super-users, told that story that when Dell started their community 9 years ago, they pulled 30 technical support agents to do moderation. But over nine years later, as the size of the community has increased tremendously, the number of moderators has shrunk, not grown. Now they have 5 moderators. The community takes on that moderation role.

Check out the webinar for more really useful tips on launching online communities.

Posted on
by

In the 1990s, activists targeted companies like Nike for their sweat shop labor and child labor abuses. Frequent headlines and photos of protestors with boycott signs picketing Nike and other athletic clothing companies and of child laborers found their ways into newspapers, the nightly news, and web sites.

In the 2000s, the focus changed to environmentalism, and the targets changed to oil companies, Monsanto, the WTO, and the worst polluters. The technology segment lived in fear of the day that they, by virtue of their size, high visibility and brand name recognition, and immense electronic waste streams would become the targets of environmental activism. The big consumer technology companies, such as Apple, Dell, HP, and Sony all rushed to proclaim their environmental friendliness and leadership to avoid becoming the next Nike.

But in the midst of this, a million small activists are bringing attention to acts that may have a small impact on an individual basis, but collectively create frustration: the bad customer service of big corporations.

Google “Verizon sucks” (or any other corporation), and you’ll see tens of thousands of hits, as individual customers related their bad experiences at the hands of these mega-companies. People don’t need consumer reports to rate the customer service of a technology company, they just need to start reading a few product reviews on Amazon, or a few posts in the blogosphere. The companies are listening too: using both manual and automated processes, companies large and small are combing the web to find out what customers are saying.

The impact of this is significant. Where once a bad customer service experience might have been related to two or three people in person, now that same bad experience is shared with hundreds or thousands of people. My personal blog post on Verizon’s poor customer service treatment of my mother is consistently one of the top ten pages on my personal blog, accounting for about 7% of all of my monthly traffic six months after the initial posting. From my post:

Every mom out there has a son who blogs and will gladly tell the story of the bad customer service their mom received at the hands of Verizon. The risk and exposure associated with bad customer service is only going up. Not only does Verizon risk losing their customer to the growing number of phone service alternatives out there, they risk losing many other prospective customers who hear the bad customer service stories.

Or take the case of Mona Shaw: Shaw ordered Comcast service. On the day of the installation appointment, she waited for a service representation all day, and he never showed up. He finally showed up two days later, and only partially completed the work. Comcast then inadvertently shut off all service to Shaw’s house.

On the following day Mona Shaw went to the local Comcast office, and waited for hours to talk to a manager, only to be told late in the day that the manager had left for the weekend. After waiting all weekend, Mona Shaw, 75 years old, and with a heart condition, went back to the Comcast office on Monday with a hammer and went to town on the keyboard, monitor and phone of a customer service representative.

The cost of this to Mona? A $345 fine. The cost to Comcast? Far more than two hundred and fifty blog posts and web pages tell the story of Comcast’s poor customer service.

As mass market media has known for years, the inflammatory, sensational, and controversial sell newspapers and gain TV viewers. This holds true in the blogosphere as well. My own experience is that one post ranting about a bad product received more traffic than fifteen typical posts on how to improve the customer support experience.

All of this creates tremendous pressure for companies to provide consistently satisfying customer service experiences in the first place, and develop effective and speedy responses to address negative reactions in the blogosphere and on product review sites, such as Amazon.