The Practicalities of Adding Chat to Your Support Center's Contact Channels


by Judy Benda
May 23, 2012

According to the 2010 HDI Support Center Practices & Salary Report, only 19.9 percent of all centers are offering chat as a contact channel. With adding value and reducing costs at the front of most IT leaders’ minds, is this the right time to increase your support capacity by adding chat? And are the benefits as real as they are widely believed to be?

If you are considering utilizing chat, it’s a good idea to start by asking yourself these questions:

  • What are you trying to accomplish with chat? Is it simply a cost reduction or also a capacity increase? 
  • What contact channels do you offer today? 
  • Why are you interested in chat, specifically, versus other channels? 
  • What does senior management have to say about the chat option? 
  • What do your analysts say?

The answers to these questions will help you predict your organization’s success with launching a chat strategy.

In my experience, organizations with a relatively small, dedicated service desk staff (five or fewer) struggle to manage phone, e-mail, web requests, and chat. And I have seen few organizations achieve success by having single agents manage all three primary methods simultaneously (a phone queue, an e-mail queue, and chat queue). Likewise, the dual focus of chat and another method (i.e., phone) doesn’t result in cost reductions or increased agent efficiency.

Based on interviews with several industry analysts, as well as my own experiences with clients, I have concluded that chat is being sought for three primary purposes:

  1. To decrease costs; 
  2. To increase capacity; and 
  3. To support the emerging workforce.


Senior management may, at first, view chat as a potential distraction. If the traditional methods of phone, e-mail, and web ticketing have resulted in high customer satisfaction and metrics reveal adequate agent utilization, management will likely be reluctant to offer this new method. On the other hand, especially in organizations with younger employees, this method may be required to meet VOI targets,[1] even if the cost and efficiencies are similar. Likewise, the service desk’s reputation will increase along with its ability to offer the variety of support channels desired by different generations. We know that the emerging workforce prefers text over voice and “realtime/just-in-time” solutions over knowledge base searches.

Chat Adoption

Chat’s adoption rate has been slow, though it has gradually increased over the past four years. The 2010 HDI Support Center Practices & Salary Report reported a 6.3 percent increase between 2007 (13.6%) and 2010 (19.9%), with a slight dip in 2009, likely the result of the general economic downturn and staff reductions, as well as a reluctance to invest in new technologies. Even though HDI’s research shows that the cost of chat increased from $10 in 2009 to $15 per incident in 2010, it still costs less than phone, which was $20 per incident in 2010. This supports the assertion that increased use of chat can reduce overall costs.

The Chat Experience

Analysts who support chat—either as a single channel or in combination with e-mail—have expressed great satisfaction with the tool. They like having the ability to support dual, text-based channels. However, when they were asked to monitor phone queues and chat simultaneously, they were greatly dissatisfied. The consensus was the chat session often didn’t achieve the conversational rhythm desired by clients. One goal of chat is to emulate conversation, but without the long periods of idle time, both on the analyst and customer sides. But there can be big wins for the service desk’s reputation. Offering additional channels demonstrates a willingness to meet customers’ needs and to support a multigenerational workforce.

One of the oft-sought benefits of chat is increasing the service desk’s overall capacity without increasing costs. In some cases, the hypothesis was that a single analyst could support multiple chat sessions simultaneously, which wasn’t possible with voice. The early reports were that it was possible for an analyst to maintain four chat sessions, but my observations and interactions show that the maximum number of possible sessions is three, though two is more realistic, especially in centers that don’t have large support teams and are early in the implementation process. However, even at two chats per analyst, with low idle time, support centers have realized an overall cost reduction.

Here are a few questions to consider when calculating the ROI for chat: 

  • What is your current total contact volume? 
  • What is the volume by source (e.g., voice, e-mail, web ticketing, walk-in, etc.)? 
  • What are your individual analyst volume goals, by source? 
  • What is your average speed to answer or respond, by source? 
  • What are the most frequent requests you receive? 
  • Do you have a portal with the ability to add chat, or will there be expense involved in adding the capability? 
  • What tools do you currently have in place that could be maximized to support chat (e.g., Office Communications Server, remote access tools with chat capabilities, etc.)?

Creating a simple spreadsheet can help you identify your actual costs and expected return from supporting chat. The goal is to replace some of your voice contacts with chat and to drive easily answered questions to chat. This is where the real benefits of chat become apparent. Answering the questions above can help you take the next step toward realizing the increase capacity/decrease costs goal. Here are some questions that will help you achieve this goal:

  • What is your per-analyst capacity today (i.e., tickets resolved per day/week/month)? 
  • If your analysts could take more complex requests via phone while answering more routine questions via chat, would this be a benefit to your organization? 
  • Are your analysts able to handle up to three to four chat sessions simultaneously, for more routine issues?

Once your organization has decided to introduce chat as a contact channel, it’s time to decide what type of chat to adopt.

Virtual Assistants versus Chat

Virtual assistants give the customer the impression that a live agent is responding, when, in fact, it’s a script-based automatic response. The advantage of virtual assistants is the ability to automatically summarize the request and capture a few key points of information that can be integrated in the incident-tracking tool. As long as the time between when the virtual assistant picks up and when real-time chat is launched is relatively short, my clients have found virtual assistants to be fairly successful. Remember, the wait times for chat need to be relatively short because one of the perceived values of chat by customers is the short wait and quick response time. Also, chat should always be conversational.

It can be daunting to wade through the various chat and integration tools on the market today, from tightly integrated tools with robust capturing features (i.e., footprints and mapping) to stand-alone chat tools launched from your Intranet. If your service desk wants to use chat in tandem with a knowledge management system (self-help), you would probably want to use the former chat tool, with features like footprints and mapping that can let the analyst “see” where customers have been in the knowledge base, rather than directing customers to solutions they’ve already tried. Nothing frustrates customers more than having to repeat attempted solutions.

In general, your call-tracking tool vendor is a great place to start your search; local professional groups, such as HDI’s local chapters, can also provide great peer-to-peer references. As part of the evaluation process, consider the information that has to be captured during the interaction. Some organizations require complete real-time capture, while others allow the “cut-and-paste” method. However, depending on the requirements and costs, ITIL incident management best practices favor the former, stipulating that each interaction should be captured in its original states to preserve the integrity of the information.

Overall, strategy is key. You have to balance the costs against the rewards. The worst case would be to launch chat as a channel and then have to remove it because of system or integration constraints. We all know how tough it is to get customers give a contact channel a second chance when it has been disappointing or frustrating in the past.

So, when is the “right” time to integrate chat? Answering the questions below should lead you to a solution that is right for your organization: 

  • What are your web self-service capabilities? If you don’t have self-service in your organization, you may want to consider launching self-service (with a knowledge management process) with a chat option. This will helps you drive simple cases to chat sessions, which are the type of cases that are most likely to be resolved successfully via chat. 
  • What are your knowledge management capabilities? How mature are they? If your organization has a mature knowledge management program, launching chat will be a relatively easy endeavor, as much of the searchable knowledge already exists for both the analyst and the customer. 
  • What is your search threshold? Consider adding a time limit to your search function, so that after customers spend a certain amount of time searching your knowledge base or FAQs, they will be prompted to launch a chat session. This can alleviate frustration and, even if customers don’t choose the chat option, it is still a “value add” for the organization, since it gives customers a positive impression of your organization’s service. 
  • Are you launching any new offerings? Consider launching chat at the same time. For example, Windows 7 is on many organizations’ radars this year. How about driving “how-to” questions during a launch to an alternate channel, like chat?
  • What are your budget constraints? Are you “doing more with less”? If your organization’s goal is to drive down costs, chat is a profitable option (again, from $20 for phone to $10–15 for chat, per incident).

Over the past several years, customers have been increasingly insisting on chat. “Digital natives,” for example, prefer the instant response chat offers, but it may take some time for chat to take root in your organization. At the beginning, the primary goal should be a reduction in voice traffic, which is high cost/low benefit. However, since it is difficult for analysts to manage voice and chat contacts simultaneously, you should task one or more staff members with handling chat queues independent of the phone queue, though they can manage e-mail queues or write knowledge base articles while working the chat queue.

Also, bear in mind that chat is at its best when it is used in connection with self-service or self-help systems, like knowledge bases. Many online self-help functions aren’t immediately successful for customers, so chat should be the first point of contact beyond self-help. In organizations with mature knowledge management processes, virtual assistants can facilitate the chat process by collecting preliminary information in response to a script, which analysts can reference when they take over the chat session. Overall, regardless of organizational maturity, chat allows agents to quickly handle simple issues, leaving more complex issues for the phone queue.

 

Judy Benda is the end-user computing practice director for Long View Systems. She is an experienced support center director, trainer, consultant, public speaker, and expert on the support industry. Judy’s list of consulting clients includes internet security organizations, outsourcers, the military, and Fortune 50 clients; in addition, she has mentored help desk managers throughout the United States and Canada, and is a certified ITIL v3 instructor.

Tag(s): technology, customer service, desktop support, support channels

Related:

More from Judy Benda :

    No articles were found.

Comments: