by Yuri Mediakov, PM at BraveGeeks
I went to the movies recently and noticed a woman standing by the exit. As people exited the theater, she would quickly thank them for their visit and invite them to come again. She repeated this platitude maybe 50 times over the course of a few minutes. I thought to myself: Does this actually work? Do people actually visit the theater again just because this woman repeated her dull, memorized phrase to them?
One day, I contacted my cell phone provider. I said that I’d be traveling to another region and asked them to advise me about my best roaming options. The woman responded by sending me a list of all possible options and a list of all the regions for each option. To be honest, that didn’t really help.
The same thing happens when I write to an online store’s support team, or when I go to the dentist or the bank. All of my questions get a scripted response and a polite smile.
Now I’m realizing that customer service for my projects used to work the exact same way. And I’m ashamed of that
I used to think that it was very important to provide a stable level of service. What if someone on the support team blurted out something unscripted, without thinking? That would hurt the company’s reputation! I also used to think that it was only important to have a cool product, and it was enough for customer service to be cheap and “stable.”
I think that large companies hold the same belief: scripts are written for basic interactions with customers, work processes are regulated, and jobs are created that pay minimum wage. There’s also high turnover, and people need to be trained quickly. Because of this, the scripts are very comprehensive, so that any average Joe could figure them out.
Small companies do this too; after all, every small company wants to be like the bigger ones. And it’s all in vain. I, for one, don’t do this anymore.
Humans should stay humans
People often write to support when the interface they’re working with confuses them and they can’t figure out if they’re on the right track to solve their problems. There’s nothing they want less at that point than to have to extract the information they need from yet another robot-like person.
Humans are different from robots; humans can empathize. Moreover, humans can help find solutions to problems because they are capable of understanding them. A member of the support team armed with a script doesn’t empathize — they go through the script, from one section to another. They react with boilerplate phrases. They don’t try to help. And this is our fault: we gave them the script and told them to follow it.
Now, we don’t write scripts for our support team. Instead, we learn to help users together: we work out how to understand problems, how to look for solutions, how to talk about them. Stock phrases were ditched along with the scripts — no more “Hello, this is Catherine, how can I help you?”
I used to need scripts to make sure that people weren’t making mistakes. I thought that it was better to have a mistake in the script than to have someone make up something to say — and that’s bad. That kind of approach actually creates employee turnover. No one likes mindless work.
Now I trust my support team, and they make mistakes. Mistakes don’t bother me, as long as we truly want to help users and are doing everything we can to solve their problems. Users reciprocate: they feel comfortable when problems arise, and they help us find solutions.
It’s also very frustrating when the support team is unable to help. When they nod, express sympathy, and ask the user to wait while some wise, all-knowing department looks into their question. This just means that the formalities are about to begin. The user’s problem won’t get solved, and they’ll waste a ton of time.
The support team needs to really be able to help: they need to fix something in the user’s account, change their password, or correct some common mistake. At worst, they need to compensate the user for an inconvenience.
Now, we don’t have first and second line support — we don’t shift responsibility around.
Sometimes we notice a problem that affects more than 5% of users. In these cases, our first priority is to develop materials that enable the support team to make manual changes in order to help users. Then we fix the actual product. This approach doesn’t always work out, but it has helped a few times already — it’s easier to create materials for the support team than it is to work on product development, and support materials are easier to test.
Users feel cared for immediately; they don’t have to wait for a release that fixes bugs.
It’s great when common user problems are described in a special reference section. It decreases the number of canned responses the support team has to give, and it enables the team to spend less nervous energy copying responses from similar tickets.
For many people, writing to support signals admitting defeat in the battle with the interface. Finding the answer on your own is like scoring a solo victory. Knowledge bases also help train new employees, since they contain the answers to common user questions.
You can’t just sit down and make a knowledge base, however; they should be put together gradually by the support team, based on real questions asked by real users.
Study existing problems
A good customer service team isn’t able to solve all of a product’s problems. They help with some of them, and they give the product a human “face.” User problems must be studied, and user experience must be improved.
When a support team begins speaking sincerely and honestly with users, support becomes more than just a user-retention system — it becomes an excellent channel of communication. You can learn a lot of interesting things about your product by studying the conversations your support team has with users.
There’s even something to learn by examining indirect cues. When there are certain things the support team has to do very often, this is a reason to take a closer look at some specific part of your product. The problem isn’t that the support team is overworked; it’s that there are still users who aren’t asking questions. Those users are liable to switch to a competing product.
Good customer service prevents customer churn and helps improve your product.
I’m convinced that turning people into robots is a bad idea. I’m convinced that canned answers from a script aren’t useful, that customer service needs actual people — that is, if you’re serious about helping people, honestly, without hiding behind corporate courtesy.