If you’re reading this, you likely have either just implemented live chat on your website or are thinking about it. If you’re the latter, let us help you make your decision + Read More
We all like to look at the positives within customer service – its ability to surprise, delight, and offer real help which makes people’s lives a little bit better.
But a lot can be learned from looking at the negatives too.
And it’s certainly better to learn from the mistakes of others than to go through that pain yourself.
Here are five real-life examples of live chats gone horribly wrong. Systemic errors within software setup, resourcing, and agent training in these examples have led to nightmare customer scenarios going viral, with companies scrambling to control the damage done after the event.
Don’t fall into the same traps these companies did – read on for our advice on how to disaster-proof your live chats, and guarantee the happiness, loyalty and respect of your customers.
This experience went public very quickly. There are a few issues within this chat transcript, so let’s break it down.
Agents are being assigned chats, then rapidly leaving them, with far too much transferring occurring. The canned responses they are using for this are not useful in helping the customer understand why this is happening. When the customer gets through to someone who sounds like they could help, he is again referred to using another canned response with no explanation why.
Agents also aren’t reading chat histories. The customer is forced to repeat his question three times, all the while getting no closer to having his issue understood.
A Genesys Global Survey has shown that by far the most requested customer service improvement from customers is “Better Human Service”. Your agents need to be able to recognize the impact of their actions on the customer, consider how situations feel from their perspective, and treat them like a human being, not a ticket number.
You also need to make sure that your customer is getting through to the right agent to begin with, to avoid unnecessary transferring.
This issue can be a tricky one to resolve, but here are some tips to help:
This complaint was posted on a forum at 19.00 precisely. In this case, it took the customer just 17 minutes of waiting for a reply to compose a complaint which ended up online at lightning speed.
When you offer live chat, customers expect agents to respond quickly to queries. Leaving a customer waiting a long time for a chat response isn’t any different to taking a telephone call from them, putting them on hold, and leaving them there. You’re still wasting their time.
There are several things you can do to prevent this from occurring:
This chat transcript went viral after a customer spent nearly an hour with an agent trying to explain his problem.
During the chat, the agent referred to the customer as “Maam” even though he is a man, used very poor English, and didn’t understand what he was saying or what the best course of action would be.
It’s vitally important for agents to demonstrate to customers that they understand their issue. Where they don’t understand, they need to be able to recognize when they no longer have the ability to help, and refer for further assistance in a positive and solution-focused way.
So what can be done to prevent this?
Here, the customer was stuck in a long queue, with canned messages adding no value during the wait time. Once it seemed that the customer was nearly at the top of the queue, system issues occurred, closing the connection and losing the customer their space in the queue.
Although you can’t help system issues which occur on the customer’s end, you can minimize the annoyance of long queues in a few ways.
In this situation, a customer was the victim of identity theft, with the impersonator managing to obtain the customer’s full address, then using this to impersonate the customer with other companies. The source of the leak? A live chat interaction.
This chat transcript, which the real customer was eventually sent, shows the impersonator passing security with an address which wasn’t registered to the customer’s account (it is the address of a hotel where the customer had once registered a domain name. The only thing this has in common with the customer’s real address is the zip code.)
The impersonator then goes on to obtain the customer’s real address.
There are a number of things here that went badly wrong, and a number of things which could have prevented this.
Do any of these disaster scenarios ring true? Or do you have any ideas on what else could be done to prevent these chat fails? Leave us a message in the comments below.
Download our annual Live Chat Benchmark Report for access to data-informed insights into live chat best practices and optimization.Download Now