Helping End Users Help Themselves

Posted on
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone

Not too long ago, if consumers needed or wanted to contact a vendor, telephone was the only channel available. Depending on how seriously the vendor took the concept of customer service, the wait was either a brief interlude accompanied by 1980s hits of Rod Stewart, the ability to hit “0” if so desired, the infamous message that announces, “Your approximate wait time is 17 minutes, or you can press ‘4’ and leave a voicemail message that will be answered in ‘X’ hours (or days),” or a side-trip through eight different phone options, in what has come to be known as “phone hell.” We won’t even talk about speech-recognition software. We’ve all spent 15 minutes on the phone waiting to complete a transaction that should have taken 90 seconds and wondered, “If we can send a man to the moon, why can’t we do better then this?”


The answer to that question depends on how creative, sympathetic, imaginative and customer-centric the vendor actually is when it comes to serving customers. If you’re lucky, the vendor will deploy an intuitive, fun and feature-rich Web portal that you can use to do everything from ordering a copy of a form to submitting a request for medical leave. Assuming it is built with technological integrity, it will need to be marketed in a way that ensures customers will actually want to use it, will try to use it or will ask for help if they can’t use it.


What’s In It for Me?


Many vendors equate providing a Web portal itself with success—this is the “build it and they will come” school of thought, and it is frequently wrong. The assumption among service and support consultants, support managers and event speakers has always been that one-third of users will love the chance to help themselves and need no convincing to do so, one-third will use a self-help tool if they are shown how, and one-third will hate the idea of self-help from the beginning. The goal of any self-help implementation project is to keep the first third happy, persuade the second third to try it and convince the last third that it is worthwhile to try it. Deploying a tool does not mean that it will be used. Adults need the “WIIFM” (What’s In It For Me?) question answered. Many self-help projects fail because the people who have implemented them and the management that approved the implementations frequently confuse the implementations with success. Ron Muns, CEO and Founder of the Help Desk Institute (HDI), reminded planners of self-service projects in the November 11, 2004, issue of The Muns Report, that, “If not properly introduced and implemented, end user (customer) self-service tools will fail.”


Marketing the Self-Service Tool


The best organizations answer the WIIFM question dozens of times each day for their customers until it becomes a mantra. Answering this question is a marketing, sales and leadership challenge that can be met with the following tactics:



  • Explain the value of the new self-help system: In every communication, months before the implementation begins, every executive, manager and supervisor in the organization should have a set of “talking points” that they are using in every communication, meeting and training class that explains why the organization is moving to self-service and how it will be doing it.
  • Make the system Web-based, not Web-enabled: Author Kathy Hendrickson defines the difference between Web-based and Web-enabled this way: “Web-based literally means that the application was written specifically to run on the Web. An application that is Web-based offers end users full application functionality from any browser without the need for client-side software. When software is written specifically to run from the Web, it means that configuration or customizations made on the server to the software are immediately, universally available to all the users. Web-enabled is a term typically used to describe the add-on Web-browser component of an application designed to run in a client-server environment.”
  • Train the support staff to direct customers to the Web site: The HR Call Center staff at Key Bank is a master of this technique. With eight staffers taking almost 1,000 calls a day, they deal with every conceivable HR and payroll-related topic imaginable. The call-center staff repeatedly, continuously and at every opportunity, kindly, politely, professionally and skillfully directs Key Corp. employees to the bank’s Web-based HR portal, called HR Online. From either their homes or their offices, employees can view their pay vouchers, download insurance forms, complete their timecards, check their accrued vacation time, and apply for vacation or days off and complete dozens of other HR-related functions.
  • Document the benefits of self-service and share: When Key Bank was preparing to roll out the payroll portion of its HR Online system, every employee from the CEO down to the newest teller was provided a color glossy, four-page brochure that contained an example of the new pay voucher and a list of FAQs about the new system and instructions on how to use the system. Managers at all levels received a PowerPoint briefing on the rollout and the call-center staff had replicas of the new pay voucher weeks before the rollout began, along with supporting documentation for training purposes and a test environment in which to practice its functionality.
  • Optimize ease-of-use: Although it may seem obvious, if the system is too complex to use, difficult to understand and annoying to look at, the chances that it will be used will nosedive in direct proportion to the end user’s level of annoyance. There are five criteria that should be kept in mind to avoid this dilemma:


    • Focus groups: Create a group of average users during the design and testing process, and use them as a focus group to evaluate all aspects of the end-user-facing product. Ask them what they think and take what they say seriously.
    • End-user surveys: Prepare for on-going customer satisfaction surveys and the use of additional focus groups. Organizations that stay close to their customers, listen to them, respond to what they say and make them feel involved will be more successful than those that let the IT department plan and implement everything with no outside input.
    • Metrics and analysis: Collect, analyze and react to trends identified from Web usage metrics such as click-streams, time-on-site and most popular sections of the site. Metrics should be measured on a monthly, quarterly, year-to-date, and yearly basis. Look for trends, problems and end-user complaints, and make conscious decisions about how to respond to them.
    • Alpha and beta tests: Identify tasks that range in difficulty from easiest to almost impossible to complete, and determine whether any experiences are frustrating, difficult to complete, time-consuming, etc. If you are having trouble adding a dependent to your medical insurance during a hypothetical open-enrollment period, imagine the difficulty the newest employee will have. If it is difficult to use, people won’t use it, so test it like your job depends on it.
    • Adapt quickly: All of these activities will produce reams of data and tons of information that will need to be analyzed and acted on quickly to tweak the Web portal. Quickness, not recklessness, is a major key to success in the implementation of a self-help tool. If changes and upgrades take too long, the end users will lose confidence in the tool, their frustrations will grow, and you’ll have some very stressful explaining to do to a large number of people. Plan for upgrades before the rollout begins so your end users see and experience a steady improvement in the tool and realize that they ar
Share on Google+Share on LinkedInShare on FacebookShare on RedditTweet about this on TwitterEmail this to someone


Posted in Archive|