Everywhere I go, I find support executives interested in web-based support, specifically chat. By \u201cweb-based\u201d support I\u2019m not talking about anything futuristic or complicated; I\u2019m 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\u2019s not. There are a lot of wrecks littering the bottom of the sea of web-based chat support. But why?<\/p>\n
The first why, as always, is why should you bother? There are a couple of reasons:<\/p>\n
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\u2019t talk to a second customer. . .or at the very least, it\u2019s 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\u2019re chewing the fat with the user on the phone while their system reboots, you\u2019re actually (literally) killing time. . . time that could be used to service another customer if you weren\u2019t 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\u2019 time could mean enormous productivity gains.<\/p>\n
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.<\/p>\n
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\u2019ll 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\u2019s 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.<\/p>\n
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\u2019s 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.<\/p>\n
YOU: \u201copen up a web browser\u201d
Customer: \u201cOk, what next\u201d
YOU: \u201ctype in\u00a0www.acmesupportportal.com, and hit \u2018Enter\u2019\u201d
Customer: \u201cI did and nothing happened\u201d
YOU: \u201ccan you read the address back to me\u201d
Customer:\u00a0www.askme.support.portal.com
YOU: \u201cit\u2019s acme A-C-M-E. Not ask me. And you don\u2019t need the dots in between. It\u2019s all one word\u201d
Customer: \u201cstill nothing happened\u201d
YOU: \u201cHmmmm. What are you seeing?\u201d
Customer: \u201cWait! What is a \u2018web browser\u2019? Is that like the internet?\u201d<\/p>\n
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.<\/p>\n
If web-based chat support is in an isolated silo, it may not be much good. But it doesn\u2019t 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\u2019t have the problem of translating voice to text and you break the one-to-one relationship required by the phone.<\/p>\n
I\u2019m 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.<\/p>\n
By: Nathan McNeill<\/p>\n","protected":false},"excerpt":{"rendered":"
Everywhere I go, I find support executives interested in web-based support, specifically chat. By \u201cweb-based\u201d support I\u2019m not talking about anything futuristic or complicated; I\u2019m 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. […]<\/p>\n","protected":false},"author":26,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[9],"tags":[39],"class_list":["post-10564","post","type-post","status-publish","format-standard","hentry","category-blog","tag-english-fr"],"yoast_head":"\n