··· Chatra All books
§§ Table of Contents − − − − − − − − −
Ultimate Guide to Difficult
Conversations
1. Introduction 2. When you don’t know the answer 3. When you have to transfer a customer to someone else 4. When a customer requests a feature or product 5. When a customer asks you for a favor that you cannot do 6. When there’s something wrong with the delivered product 7. When you close the conversation 8. When a customer is angry 9. When a customer is unwilling to pay 10. When a crisis occurs 11. When you have a frequently complaining customer 12. When customers complain on social media 13. When you have legal issues 14. When you have to deliver bad news 15. When you have an abusive customer 16. When customers cross boundaries 17. When the customer speaks a different language 18. When a customer asks a vague question 19. When customers ask when something is going to be available 20. When you or your fellow agents made a mistake 21. When a customer wants to speak with a manager 22. When you can’t resolve the issue right away 23. When you need to let a customer know that it was their mistake 24. When a customer reaches you by mistake 25. When a customer asks how your product is different from others 26. When a customer is worried about how secure your service is 27. When a customer says that they forgot their password 28. When you want to point a customer to your documentation 29. When a customer violated your terms of service 30. When a customer is not tech-savvy 31. When a customer is right, but your policy is not 32. When a customer sounds like a bigot 33. You’ve got this!
11.

When you have a frequently
complaining customer

Every company has a customer that every support person knows. At one company, we had Walt, and he would reach out to us almost every day about a very specific part of the product that he used more than anyone, and that we hadn’t really developed into anything fully. It had started as a test product that we opened to a few customers, and he was one of them. He continued to use it far longer than we anticipated anyone would, and he loved it. But the thing that he loved wasn’t fully-baked, and so he emailed frequently about bugs or issues that only a super-user would have found…and we never fixed them.

We didn’t think about this at the time, of course. We would just see Walt email in, roll our eyes, and ask “Who wants it?” because we knew it would be yet another frustrated, disappointed email that never came to anything.

In our case, using root-cause-analysis, or the 5 WHYS Approach could have helped us get to the bottom of the situation more rapidly. It would have eased Walt’s frustration, and saved the support team numbers of hours talking to Walt on the phone, via email, and sometimes through chat. Going through this root-cause-analysis with a customer probably takes around 15 minutes or so, if done via phone.

So, for Walt it might have looked something like this:

  1. Why is Walt unhappy? Walt is unhappy because the part of the product doesn’t work as he wants it to.
  2. Why doesn’t the product work as he wants it to? Because we built it as part of a hackathon and weren’t intending it to be fully put into the product.
  3. Why didn’t we intend to put it fully in the product? Because it doesn’t fit with our product roadmap, but lots of people ask for it so we wanted to do it at least partially.

There is the root cause. We, as a company, build this part of the product as a hackathon with the intention to never build it out fully. In order to get Walt to stop emailing so frequently, we needed to set those expectations for him clearly. This would create a better experience for him, as he’d have a more upfront view of what to expect (though there would likely be some pain to start), and a better experience for us as we’d be receiving fewer emails.