Everywhere I go, I find support executives interested in web-based support, specifically chat. By “web-based” support I’m not talking about anything futuristic or complicated; I’m just talking about getting users to contact the support center via the web (through chat or some other request mechanism) vs. picking up the phone. Sounds simple. Should be easy. But it’s not. There are a lot of wrecks littering the bottom of the sea of web-based chat support. But why?

The first why, as always, is why should you bother? There are a couple of reasons:

Starting customer support sessions from the web breaks the one-to-one relationship established by the phone. Think about it: if you are talking to one customer over the phone, you can’t talk to a second customer. . .or at the very least, it’s very awkward. But you can handle multiple customers simultaneously via chat. While troubleshooting a typical support incident, you end up watching a lot of progress bars. You have to install software, reboot the system, download files, etc. All of this takes time, and the dirty little secret of support is that the progress bar progresses whether you watch it or not. So while you’re chewing the fat with the user on the phone while their system reboots, you’re actually (literally) killing time. . . time that could be used to service another customer if you weren’t tied to the one-to-one relationship required by phone. So switching to chat opens up the possibility of multi-tasking without losing productivity on individual incidents. This is huge. Multi-tasking on two incidents at once for just 20% of your reps’ time could mean enormous productivity gains.

Secondly, the web is a good interface to other forms of support. The phone is not. But before I go too far into this, I have to give you a little more information on how support centers get web support wrong.

A lot of wrecked web support initiatives have been the result of putting web support in a silo and not connecting it with other forms of support, thus creating a dead end for your customers. If your customers find that your web support channels almost always result in an escalation to the phone, then the next time they’ll just pick up the phone. If web support is a silo that fixes the problem 60% of the time and phone support is a silo that fixes the problem 100% of the time, then why (unless from the goodness of my heart) would I use the 60% channel?

What you need to understand is that the web is a channel; it is not a destination. Users want to get their problems resolved – that’s their desired destination. The web is a channel, the phone is a channel, email is a channel, but the destination is a fixed problem. So in evaluating the strength of various channels, one needs to consider not the channel itself, but how quickly and efficiently it leads to the tools and techniques that actually solve the problem.

By this criteria, the phone is a lousy channel. We all know that walking through complicated support issues is painful over the phone, but think of how long it takes to employ ANY of your other troubleshooting tools and techniques over the phone. Whether it’s sending a file, directing the user to a website or knowledge base article, running a diagnostic script, or starting a remote support session, executing any of these over the phone involves a translation from voice to text. This translation is time-consuming and frustrating.

YOU: “open up a web browser”
Customer: “Ok, what next”
YOU: “type in www.acmesupportportal.com, and hit ‘Enter’”
Customer: “I did and nothing happened”
YOU: “can you read the address back to me”
Customer: www.askme.support.portal.com
YOU: “it’s acme A-C-M-E. Not ask me. And you don’t need the dots in between. It’s all one word”
Customer: “still nothing happened”
YOU: “Hmmmm. What are you seeing?”
Customer: “Wait! What is a ‘web browser’? Is that like the internet?”

Even if your customers are tech-savvy, it can still take a long time to get a long text string translated over a voice channel. However, if the customer starts from the web, like a chat session, they are already communicating with you via text, and moving from text-based communication to other forms of support (articles, diagnostics, etc.) is effortless.

If web-based chat support is in an isolated silo, it may not be much good. But it doesn’t have to be this way. If, from the web, you connect your customers with all of the tools and techniques that you employ in support, then it speeds up the support process. You don’t have the problem of translating voice to text and you break the one-to-one relationship required by the phone.

I’m not going to pretend that all of this is like falling off a log. Your team has to adapt to a different way of doing things and your customers (at least the ones over 30) may still want to call sometimes. But leveraging the web and chat as a support channel can help you get to the ultimate destination of fixed problems faster.

By: Nathan McNeill