Technique 5.11: Self-Service Success

Last updated
Save as PDF

The benefits of self-service are profound. When done correctly, it becomes the path of least resistance and best results for the audience you serve. The goal in designing the self-service mechanisms is to provide access to knowledge with the least amount of effort on the part of those who are seeking knowledge. We have learned that designing such a system is not trivial. To deliver self-service in a way that minimizes the requestor's effort and maximizes their success requires careful thought and planning. If done well it is mutually beneficial for both requestors and responders.

First, let's define what we mean by self-service; we use a broad definition. Self-service is the mechanism by which anyone can solve an issue (an exception) without an interaction with others. Historically, the most common form of self-service has been a web portal offering information such as frequently asked questions and a searchable knowledge base. However, many of the Consortium members are investing in integrating self-service into the user interface for the product, application, or service. This moves the self-service experience from a distinct and separate event to an integrated experience within the product. Additionally, technology vendors are investing in automation that will detect and repair issues or programmatically assist with the resolution of issues. Regardless of the approach, self-service success is dependent on knowledge.

Have a Strategy and a Process of Continuous Improvement

It is important to develop a strategy for self-service. We should be very clear on why we are developing a self-service capability. Some of the items that should be included are:

Vision statement
Who is (are) the intended audience(s)?
Goals: what does success look like?
Measures
Assessment and continuous improvement process

The greatest value from self-service comes from viewing it as a customer engagement strategy. It enables us to leverage what we know to support greater user success. While a side benefit of self-service is cost reduction for the organization, it is not a deflection or avoidance strategy.

Self-Service Design Criteria

In designing the self-service capability there are five key enablers we have observed about successful self-service models:

Findability - Findability is driven by three things (all of which are enabled by KCS): context, structure, and rich environment statements.
Completeness - Most of what we know, that is self-serviceable, needs to be available quickly (also a focus of KCS). While the 90/0 rule (90% of what we know is made available 0 minutes - at or before the time of case closure) is a bit provocative, we continue to learn how time sensitive knowledge is.
Access - Is it easy to find the self-service access point? Ideally access to self-service is integrated into the user interface and is context sensitive for where we are in the product. If self-service is a portal or web page, is it obvious and easy to find?
Navigation - Is the navigation in the self-service mechanism intuitive for the users and does it align with the requestor's intent? "No dead ends" ensures there is a smooth way to transition from self-service to assisted support: click to chat or click to submit. Navigation should provide for both browsing and searching.
Marketing - Self-service requires a marketing plan. The "build it and they will come" model doesn't work for self-service mechanisms. We have to take overt, intentional actions to get requestors to use it. If they have a positive experience (see items 1- 4 above) they will use it...a lot.

A positive experience with self-service means that the requestor will use it again. Not only will they come back, but they will use it a lot; in fact, they will use it more often than they ever requested assistance in the past. As a general rule of thumb, if requestors find helpful information 40-50% of the time, they are likely to use self-service again. This is the industry average for self-service success (see Service XRG for the research). In a mature KCS environment where 90% of what we know is available on self-service immediately, the success rates reported are in the 80-85% range!

Findability

It doesn't matter how much content we have available to requestors on the web - if it is not in their context, they are not likely to be able to find it. This re-enforces the need for capture in the workflow. As we discussed in the Capture practice, it is very difficult to re-create the user's perception of the issue if we are not users, and if we know the answer. Creating articles in the requestor's context requires that we capture their context or experience when they first express it. The second factor for both findability and readability is structure. KCS proposes a simple structure for knowledge articles which helps the search engines be more effective and improves the users experience. The last key element in findability is rich environment statements. The environment statements in the article helps the precision and confidence that we have the correct article for our issue.

Completeness

How many articles are visible externally, and how fast? The primary enabler of success with self-service is volume and speed. The goal is to get as much as we know into the self-service channel as fast as we can. For requestors to be successful with self-service, articles have to be making it to a Validated state (depending on the business rules) with audience set to External. In the early phases of the KCS adoption, this is driven by reuse. Articles that are reused internally are moved externally quickly. In the Optimize and Innovate phase, we want to be validating and moving externally as much as we can in the moment. The model of reuse driving validation and external visibility should be a temporary state, because we know from member experience that reuse rates on the web are different from reuse rates in an assisted model. It turns out that requestors will use a good self-service model 10 times more often than they will call us. An issue that one requestor raised but has never been reused internally might be used externally a lot; other requestors would use the information, but would not bother to contact us for an answer. Our goal is to get most of what we know into the self-service model as quickly as we can.

When do we turn on and promote web self-service? If our KCS articles are complimentary to content we already have in the self-service channel, then an incremental approach might work. If we are building a new self-service knowledge base, when do we have enough content in the knowledge base to ensure a 40-50% success rate? One key indicator of sufficient volume in the knowledge base is when the reuse rate of articles intersects with the create rate for a given domain. Plotting the team's create rate against the reuse rate over time gives us a sense of how often the users within the support organization find something useful in the knowledge base (reuse) versus how often they are creating new articles. When the lines cross it means that they are re-using as often as they are creating, or 50% of the time they are linking to an existing article. It is now time to enable and promote the self-service model.

Create vs Reuse

The point at which the create activity equals the reuse activity indicates there is sufficient content in the knowledge base to enable external requestors to find something useful 50% of the time.

Three caveats: first, the linking quality for the domain needs to be at 90% or above and the linking rate has to be in the 60-80% range. This means the internal users are using the knowledge base (creating, re-using, and improving articles) in the problem-solving process a high percentage of the time. Second, articles must be making it to External visibility/audience. And third, the content has to be in the requestors' context which reinforces the finadability factor.

Access

Designing access to self-service to be obvious and low effort is another key to engaging the audience in self-service. Making the self-service mechanism easy to find for the requestors is not trivial. As mentioned earlier, integrating access to self-service knowledge into the user interface for the product is ideal but typically requires a sizable investment. If you are using a web-based self-service portal it is important to make it easy to find by the audience you intend to serve.

Navigation

Research has shown that "no dead ends" is the number one factor for users in deciding if they would use self-service again. "No dead ends" means once the requestor has started the problem-solving process in the self-service channel, they don't have to stop and start over if they don't find something helpful. An example of "no dead ends" in the self-service interface is the click-to-submit (create an incident) or click-to-chat functionality. If the self-service model isn't helpful, there is a graceful transition to the assisted model. Because the self-service activities of the requestor are captured and made available to the responder, the requestor doesn't feel like they are starting over. An in-depth research project at Microsoft found that even when customers were unsuccessful with self-service, they were far more willing to go back to try it again if there were no dead ends.

Another key factor in requestors willingness to use self-service is the availability of multiple ways to find things. People use different methods of finding information based on a number of factors. Options for finding articles include:

A list of product specific, frequently asked questions or "top ten" articles
An index or table of contents
Basic search
Advanced search

Good user interface design enables both browsing and searching and is critical to self-service success.

The other design criteria is understanding the audience's intent in using self-service. What are the top three to five reasons people use the self-service mechanism?

Marketing

The "build it and they will come" model doesn't work for self-service. Once we have taken care of the first four success criteria: volume and speed, findability, and access/navigation, we have to think about how to get requestors to use self-service. Trying to change our requestors' behavior is not trivial. Engaging a marketing specialist is recommended. Get advice from those who understand messaging and communications and build a marketing plan.

In addition to a marketing plan, below are some tactics that have been successfully used to encourage their customers to use self-service. We offer these as observations, not recommendations; these tactics must be evaluated based on the business and customer engagement model.

Recorded message promoting self-service (when requestors call for support)
Extended hold times - make self-service the path of least resistance and best results
Turn off the phones - make self-service the only path. Requestors can only open an incident via the self-service portal (we must have high confidence that the requestors' self-service experience will be positive)
Co-browsing - as a responder solves issues, the requestor can see the responder's desktop and watch them search (teaching them to use the self-service tools)
When sending a requestor a resolution, send them the link to the article in the online knowledge base (promotes exposure)

Requestor use of and success with self-service becomes two critical measures to assess the success and health of KCS in the Optimize and Innovate phase. If the articles are not making it to the self-service model or if customers are not using self-service, the KCS implementation will stall.

For some examples of good support web sites see the Association of Support Professionals (ASP) list of Ten Best Web Support Sites. The ASP conducts an annual assessment of support sites and the criteria they use is available on their web site. It is a great collection of attributes to use in designing your self-service support mechanism.