Focus on Self-Service: Level 0

One of the top trends in the support industry over the past few years has been shift-left, which means bringing more complex work down through the tiers of support and getting the most repetitive work out to level 0, unassisted self-service. This move is important and popular for several reasons:

• It relieves the support center of the expense of simple, repetitive contacts
• It reduces the burden on level 2 and 3 support by moving some of the work to level 1
• It moves work closer to the customer, providing faster resolution and increasing customer satisfaction

Have you implemented self-service in your organization? Join HDI to share tips and best practices with your peers on HDIConnect!

Join HDI

Shift-Left is expected to continue to be a priority over the next few years, and so self-service is an important part of the discussions of improvements that can be made in support. It’s important, though, to be speaking and thinking clearly about what self-service is and is not.

Self-service: The ability for a user to complete a task without the assistance of another person, such as answer a question, reset a password, resolve a problem or download and apply a software update. Self-service is sometimes misused to describe contact methods for assisted service like web requests and ticket entry because the customer is able to create an incident or service request that is then addressed by the support center. – HDI Glossary (emphasis added)

We say “self-service portal” when we talk about a web area where users can create their own tickets and peruse the service request catalog, but those things aren’t unassisted support. A self-service checkout isn’t just a light switch the customer flips to indicate that they need assistance; it is a way for the customer to perform the tasks of checking out and paying for the goods they have chosen to buy. Creating one’s own service ticket is more like flipping the light switch: It is another way to get assistance. By clicking the submit button, the customer or user kicks off either a manual or an automated request for assistance. If it is manual, someone at the service desk will read the description of the issue and provide a solution or pass the ticket along to someone who can resolve it. If it is automated, the ticket will kick off a series of steps that will result in a resolution, or will route the ticket to someone who can resolve it. This is still assisted service.

When an end user can easily look up, locate, and apply their own resolution, we have level 0 self-service. The simplest example of this is password reset. In an automated password reset, the end user clicks a link, enters some identifying information, and then changes his/her password. No assistance from the support center is required, and no ticket is created. (If the user can’t complete the process—e.g., can’t remember their security questions—then assisted service will be required.)

There has been no major increase in the percentage of tickets created by end users for themselves over the past several years. In 2011, 18 percent of tickets were submitted via web requests (online forms). In 2012 and 2013, the percentage rose to 20 percent; in 2014 it was 22 percent. In 2015, it had dropped back one point to 21 percent.

But in no way should this lack of growth be considered a failure or “lack of adoption”—at least not without substantial further analysis. It’s not a reason to stop providing the ability for users to create tickets. This just seems to be the level at which users can and will create tickets.

Not Every Incident or Request Is Suitable for Solution by the End User

Of course we know that high-impact incidents (priority 1 or 2) should not be left to any asynchronous support channel like email, social media, or a web form, and cannot be dealt with through self-service. It’s the support center’s job to make sure everyone in the organization knows what to do if such an incident occurs.

While simple, repetitive issues or questions are suitable for self-service, more complex ones are not, and here’s why:

• The support center is very often capable of diagnosing and resolving complex issues faster than end users
• While a drop in contact volume may save the support center some expense, that expense will be transferred to other business units as users hunt for solutions
• Especially with complex issues, there is an emotional component that can be better addressed in conversation with another human expressing empathy

Many organizations remove end users’ administrative access to their computers, which immediately rules out many fixes requiring that level of authority. Although some users don’t mind getting “under the hood” and applying fixes, many do not want to change settings they aren’t intimately familiar with. Users have a level of comfort, and sometimes providing their own fixes exceeds that level.

In addition, there are cases in which the user simply wants to be guided through a solution. Even though they may be expert users of some particular application or set of applications doesn’t mean they have enough confidence to resolve an issue that is affecting their work. Assisted support should be there to provide answers and solutions in as short a time as possible and get people back to work.

There are, however, many cases in which the solution is simple, straightforward, and easy for an end user to understand. In these cases, user-facing knowledge and tools like software updates can be provided to keep incidents and requests with the lowest level of complexity from reaching the support center by providing resolutions at level 0; just don’t expect a sudden and huge drop in contact volume.

Many Knowledge Base Implementations Do Not Meet User Expectations

Well more than half of support organizations provide user-facing knowledge intended to help people resolve issues on their own. Fifty-nine percent of organizations provide a knowledge base or at least Frequently Asked Questions (FAQ) within their self-service portal; 56 percent provide this knowledge on their IT or company website (not in a portal), according to HDI research (available to HDI members here). However, the same research tells us that only 10 percent of support organizations feel that their FAQ or knowledge base is very successful, while 8 percent feel it is very unsuccessful. What is wrong?

One of the most common mistakes IT departments make in building user-facing knowledge is composing the knowledge articles from the IT point of view rather than the user’s. For example, IT often refers to the calendar and email system as Exchange while end users think of it as Outlook or simply email and calendar. Users might ignore suggested solutions mentioning Exchange, or may fail to find the relevant knowledge altogether. This phenomenon may then be compounded when IT deems self-service unsuccessful and discontinues support for it, rather than trying to figure out what is wrong.

A better approach than abandoning user-facing knowledge is to improve it through a measure called Level Zero Solvable (LZS), which helps identify the proper time to publish to users and the verbiage to use when you do. “LZS is s a metric that can be used to predict customer success with a user-facing knowledge base. It identifies knowledge articles which can be found successfully by end users using their own words to search.” (HDI Glossary) Measuring LZS helps eliminate the problem of IT using Exchange and users searching for Outlook, because it specifically measures the number of times the user’s term—Outlook in this case—can be found.

It Might Not Be as Simple as You Think

Not even password resets are straightforward. Many organizations find that their call volume for password resets actually goes up after the installation of self-service password reset. This can happen for several reasons:

• Arcane security questions that people find difficult to select and remember
• Overly complex password requirements
• Multiple passwords with differing requirements
• Password reset tools that cannot reset all the passwords users need

IT tends to do things from its own point of view, such as requiring passwords that are eight characters long (but no more than eight) and have upper and lower case letters as well as numbers (but not the same number more than once) and at least one special character for Application A and a six-letter password that cannot have special characters for Application B. Users think they will remember their passwords, but then cannot—and of course they should not be written down.

What slips IT’s mind is that many users do not use their computers or certain applications every day; in fact they may go a month without having to use that arcane password, by which time they remember none of it. The irony is that many security breaches are accomplished not through end users’ weak passwords, but through an IT system with admin as the username and Pa$Sw0rd as the password.

The Success of Self-Service: Are You Measuring or Judging?

What we don’t know from our research is how organizations have determined that their self-service efforts are either successful or unsuccessful. Do they run analytics on their websites to see what end users are looking at and clicking on? Do they know how many knowledge base articles a user looked at before contacting the support center?

We do have conversations with our members and our broader community at our conferences and HDI Forum meetings, however, and what we hear is that many organizations lack the tools and expertise to understand users’ online behavior when it comes to self-service.

Success of Self-Service Tool Types

 
HDI Research Brief: Technology for Empowering End Users, Aug. 2015

In order to truly assess the effectiveness of self-service, objective measurements must be put in place to answer questions such as:

• How many times in a given period did users search unsuccessfully and need to receive assisted service?
• How satisfied are users with the self-service system specifically?
• Has self-service helped to reduce time to resolve?

We also know, through conversations and shared content, that support centers often base their implementation and expectations of self-service on two things: Contact deflection and cost reduction. Again, these are from the IT perspective and not the users’ point of view. Users often sense this and feel that they are being used rather than being supported. This sentiment slows—or even kills—adoption.

To be clear, well-implemented self-service will reduce the volume of simple, repetitive contacts, lowering overall volume and possibly reducing costs as a side effect. The primary goal, however, should be to find ways to reduce interruptions and expedite return to work. If users can resolve an issue for themselves in less time than it takes to get through a phone queue (or receive a return email) and get a resolution, you are improving service and lowering costs.

HDIConnect is where members go to share knowledge and resources with the community. To join the discussion about this Focus Series feature, become a member today!