Using The Customer Support Experience Framework

A few weeks ago, I posted about a framework for considering the customer support experience. The framework is composed of four phases: awareness, navigation, diagnosing, and solving.

Pete Hwang, a collegeue of mine, asked if the framework could be shortcut by people using Google:

Framework makes sense. But could you argue that web savvy customers who start with a Google search shortcut the whole thing? The customer experience journey in this case: Customer recognizes they have a problem. Google for error code or best guess at describing problem. View hits on possible solutions... Corroborate entries and take educated guess at likely best solution. Hopefully, solve problem. Otherwise, look toward 2nd most likely answer. If still not solved, try a fresh google search with fresh search terms. The official HP support doc only comes into play as it receives high credibility (high ranking) on Google.

Pete's point is certainly valid. The framework isn't intended to dictate a specific support path down which the customer is forced, but instead is a thinking aide to understand their experience and compare the role that different tools play. The way that we've used the framework is by describing different support tools within an "AAA NNN DDD SSS" diagram. The letters stand for Awareness, Navigation, Diagnosis, Solution. We repeat the letters simply to remind ourselves that frequently there may be multiple steps within each phase, and that different tools may help get the customer through different phases.

Let's look at an example. In the picture, row 1 shows what most company's idealized view of the web support experience looks like. In this idealized picture, the customer thinks first of the company's web site, enters through the home page, navigates through the site using links, and ultimately finds a web document to solve their problem.

Row 2 shows a common alternative, and the one described by Pete. A customer does a Google search on a product, and again in the ideal world, the Google search's first result is a link to the support document for that problem.

Row 3 is another alternative - a Google search leads to a web forum discussion. Web forums frequently do exceptionally well in search engine results, so if a forum exists, and the problem has previously been posted, odds are good that a forum result will be high up in the search results.

Row 4 is just a hint of another tool that companies have at their disposal, but frequently don't take full advantage of. Error messages displayed by software applications or even hardware devices do much to make the customer aware of the problem, but usually do very little to help them find a solution. An error message that was linked back to a support document would directly make the link from problem to solution, and would bypass the need for navigation and diagnosis.

Please let me know if you make use of this framework. I hope it will be of use to you.

Why Content Management is Not the Same As Wikis

In the technical support documentation space I've been recommending wikis as a way to enhance collaboration on support documentation as an alternative model to the traditional approach of having a small cadre of technical writers and experts using a traditional content management tool to publish documents to the way.

While I'm an advocate of opening up the wiki to customer input, there are levels of collaboration that may make it easier for companies to get their feet wet without going so far as to open it up to customer input. The wiki could be used, for example, to allow input from other employees across the company, from R&D engineers to call support agents.

However, whenever I propose this, the established parties usually say "Why don't we just fix the content management process we have?" or "If all we want to do is collaborate inside the company, we can use the content management tools we have for that."

Wikis aren't just another content management tool however. Wikis embody design principles that encourage contributions. When Digg was first implemented, the earliest versions had a two-step process to submit a digg vote. Kevin Rose, founder of Digg, spoke about the impact that moving from a two-step to one-step process had on the site:

There was a huge shift in activity on Digg when we made the move to the one-click digg in November 2005. Once we added Ajax, activity went through the roof on [the number of] diggs. It was just insane. Just the ease of the "one-click and you're done" made all the difference in the world. Once the users grasped that the content is syndicated to friends, friends' activities then went through the roof. These small incremental steps in feature additions drove the growth.

The more direct and lightweight the process is for contributing, the greater the number of contributors. And it's not just pure volume of contributors: a simple contribution at first can then lead a user from passive recipient to enthused contributor. The editors at Wikipedia that devote much of their lives to upholding the quality of Wikipedia all started their involvement with a single, simple contribution at some point in time.

Wikis are perhaps the purest embodiment of the design principles of directness and lightweight processes. Every page has an edit button, so contributions are never more than a click away. The act of adding a few words to a document t is rarely more than clicking edit, inserting those words, and then clicking save.

Contrast that with a typical content management system: As a user who is browsing support documents on the web, and then spots an error in a document, if I've already used the content management system before, I have to then:

1. find/launch the content management system
2. login
3. navigate to the document I was already viewing, usually by an obscure mechanism that isn't the URL of the public document
4. choose to edit the document
5. make the edit
6. save the document
7. probably go through an edit review process relying then on other people to review the edit
8. wait for notification that the edit is published
9. check that the web document reflects the change

If I haven't used the content management system, I would need to:

1. Find out how the content is managed, probably by emailing peers until I get an answer
2. Find out how to apply for a login
3. Justify my need/right to modify the content (usually a lengthy process)
4. Find out how to use the system

The two choices differ so significantly in effort involved, that the result is not just a quantitative difference in the number of contributions, but a qualitative one as well: true collaboration among a large group of contributors is unlikely using a traditional content management tool, because only those whose primary job it is to manage content are likely to invest the effort to use it.

By comparison, wiki makes it clear that editing is possible, puts the edit tool only a click away, and removes the step of having to renavigate to the content to be edited. While these steps may seem small, like we saw with the Digg example, small reductions in effort correspond to large increases in contributions.

Side note: I'm currently reading Designing Web Interfaces: Principles and Patterns for Rich Interactions, which inspired some of these thoughts.

Four Phases of the Customer Support Experience

When large companies put technical support content online, the effort frequently comes with a variety of pitfalls. A large company may have dozens or hundreds of products, and each of those products may have dozens or hundreds of support documents, leading to many tens of thousands of support documents.

This can make it exceedingly difficult to find the right help content for any given product and problem. As a result, companies then undertake a variety of web site improvements aimed at helping customers get their problems solved from improving navigation, to providing top FAQ lists, interactive troubleshooting tools, and more.

But how do each of the potential tools affect the customer experience? How do they relate to each other? And what part of the customer experience are they really seeking to improve?

Here is a framework Steve DeRoos and I like to use to think about technical support experiences. To help customers get their problem solved using eSupport, there are four phases of the user experience to consider:

1. Awareness
2. Navigation
3. Diagnosing
4. Solving

Awareness: How do your customers become aware that you offer self-support help? If you're recently improved your self-support help (for example, if you've recently added forums), how will customers be aware of those changes? Most customers, particularly web savvy customers, will choose to use a website visit over a phone call to get their problem solved. But less savvy customers, or customers who previously had a bad web support experience are likely to gravitate directly to phone support.

However, the more web-savvy they are, the more likely they are to go direct to Google to get their problem solved.

Navigation: Once the customer has made the decision to use self-support, how do they find it? Do they need to navigate to a product specific area of the website? Can they search and find it? Are there multiple kinds of support content and tools - if so, how does a customer choose which one to use? One example of a tool designed to make support navigation easier is HP's Automatic Product Detection, a tool that detects what HP products the customer has, and links directly to the support pages for those products.

Diagnosing: When the customer finally arrived at the support content, how do you narrow down the specific problem the customer is having? Is it an install problem or a use problem? If it is a paper jam on an all-in-one printer, is it a paper jam for the printer portion, or the scanner portion? With regular paper or something unusual like labels or card stock?

Solving: When the problem is finally known, what are the steps to solve the problem? How do you insure that the customer follows through on the steps? If there are multiple ways to solve the problem, how do you lead the customer through each of the different ways? How do you know if the problem is resolved?

Having a framework like this helps ensure that all aspects of the user experience are considered. It also helps when considering proposal investments in eSupport: What problem is being solved? What percentage of the user base will it work for? And what is the business impact of improving that aspect of the user experience?

*Bridge photo used under Creative Commons license. Original photo by mozzercork. Shakey Bridge, Cork City, Ireland

Taming the Comment Trolls

When a large company rolls out social media capabilities on their website, they frequently worry about negative posts. A large company represents to many, a large target. Even the best companies with excellent customer service will have the occasional frustrated, angry customer.

How to deal with this? If the company moderates posts, and filters out anything negative, they will lose trust with their customers. If the company does nothing, and lets negative posts pile up, they could dominate the online community and discussions even if they are not truly representative of most people's experiences.

It's not so much whether a post is negative or postive, but whether it is constructive or destructive. A constructive post might point out a flaw in a product, but lead to a discussion about how to improve the product or work around the flaw. A destructive post might point out a flaw in a product and then proceed to personally attack the employees of the company.

Luckily, communities can police themselves. Using comment moderation features, users of online communities and websites can rate comments up or down, or report them for violation of community guidelines (such as inappropriate language).

When the right tools are in place, the constructive members of the community (who generally represent the majority) will tend to vote down destructive contributions. The company who sponsors the community or social media aspects of the site won't need to be involved in moderation, and so they won't be perceived as trying to control the conversation.

Pete Hwang, Experience Designer-Strategist at Hewlett-Packard, recently brought to my attention an excellent Wired magazine article by Clive Thompson on "how to open your website to comments without inviting the flood of toxic and inappropriate comments & flamewars that often arise".

The world’s top discussion moderators have developed successful tools for keeping online miscreants from disrupting conversation. All are rooted in one psychological insight: If you simply ban trolls—kicking them off your board—you nurture their curdled sense of being an oppressed truth-speaker. Instead, the moderators rely on making the comments less prominent.

Pete's favorite approach to disarming those destructive comments:

Here’s another hack: selective invisibility. It was invented byDisqus, a company whose discussion software handles the threads at 90,000 blogs worldwide (including mine). In this paradigm, if a comment gets a lot of negative ratings, it goes invisible. No one can see it—except, crucially, the person who posted it. "So the troll just thinks that everyone has learned to ignore him, and he gets discouraged and goes away," chuckles Disqus cofounder Daniel Ha

(It turns out that selective invisibility is a technique that actually dates to Bulletin Board Systems (BBBs) back in the early 1980s.)

Twendz: Tool for Twitter Brand or Topic Analysis

Recently Waggener-Edstrom, the PR firm, released Twendz, a tool for analyzing Twitter posts for topics. It’s a pretty great tool, and they are making it freely available.

I used it recently to search for “photosmart”, a Hewlett-Packard printer brand. You can see that results of that search.

From this search, I get a sentiment ratio (percentage of positive versus negative posts) for “photosmart”, as well as a subtopic sentiment analysis for the top five subtopics. A word cloud also lets me see other common words used. In many cases, the twitter posts also include a link to a blog post with a lengthier description of the problem/question/topic.

Now there's no excuse for not monitoring your company and products on Twitter.