Hey everyone, it's @threadapalooza time!

Here are some things I learned about communication and problem solving when working in customer support.

1. Very few people actually want to talk to support. Everyone else, myself included, will only do this if they run out of all other possible options, and if it's really important that the problem gets solved. Otherwise they'll put it off and wait until it grows big enough.

2. By the point someone reaches out to you, they're quite likely to be at least tired and irritated. Possibly furious, shouting, and making big demands. How you react to this first emotional outburst can either turn the most difficult person around, or add fuel to the fire.

3. This is NOT ABOUT YOU. It's not easy to stay calm when someone is upset and shouting, but unless you just personally massively screwed up and made a bad problem worse, they're not upset with you personally. Remembering this will help you stay grounded and calm.

4. The most important thing you can do at this stage is to get the other person to believe that you're on their side. In most situations you'll need their help to understand what exactly happened, and it's easier to get that help if they don't see you as an enemy.

5. It's never you vs the customer, but the both of you working together against the problem. Some people might not be willing to work together at first, and it's your job to help them trust you enough to do that.

6. The fastest way to earn that trust is to STOP DEFENDING YOURSELF. It doesn't matter if what that person says is right or wrong or outright ridiculous. As long as you try to counter an angry outburst with logic, you're in opposition, even if you never intended to do so.

7. Yes, explaining why things are the way they are is a way of defending yourself too. I don't care if you responded to my question after 3 whole business days because your dog got sick, or that the company policy doesn't allow you to do X. IT'S NOT ABOUT YOU, remember?

8. The only thing that can sometimes be even worse than defending yourself is trying to erase the tension with hippy-happy vibes. When you're "happy to help", and the other person is anything but happy, such contrasting reaction may make them upset even more.

9. Another thing that doesn't help at all is saying you're sorry. This against takes the customer off the spotlight and makes it about you and how you feel. How you feel about the situation doesn't matter. Save your sorries for situations where you really did screw something up.

10. Okay, so if it's counterproductive to explain why things are a certain way, or to say I'm sorry, or to say I want to help, is there anything else I can do?

Yes, it's making that person feel heard and understood. In other words, showing them empathy.

11. If they're generally talking in a calm and logical way you can jump straight to making sure you understood the technical aspects of the problem right. But if there's any emotional tension, it's much better to address that upfront before moving on to technical solutions.

12. Showing empathy is nothing more than reflecting back in your own words how this person most likely feels. Non-Violent Communication might be useful to look for core feelings under all kinds of statements, but it's not necessary. Tell them what you see, and you'll be good.

13. Put yourself in their shoes. Think how the situation looks like from their point of view. Imagine how you'd feel if you had to call 10 different people and explain why their website is broken. Tell them about it.

14. You're not actually in their shoes, so avoid saying "I know how you feel". You don't. Stuff like "I can only imagine how frustrating it must be to..." or "I'd be furious too if... " will work much better.

15. Mirror their emotional intensity. When someone says that they're "furious", don't tell them "I can see you're a bit upset". Add an exclamation where it feels natural, like "Oh no, you just had such a horrible experience with us!"

16. Matching emotional intensity doesn't necessarily mean matching the content. If they say "I want this whole fucking business burned to the ground", you can acknowledge the fury without saying you'd like to see it burned too, or using the f-word.

17. Even if you're doing it right, the person might keep adding more and more grievances. Don't worry, this too shall pass. Keep acknowledging them, and most people eventually will feel heard and understood enough to start thinking logically again.

18. Congratulations! Now you can start working on the actual problem this person came here for. Where do we start?

Again, start with summarizing all that you know so far, to make 100% sure you understand what exactly went wrong, and what the desired result should be.

19. This might feel really dumb to do at first, especially if you just spent a few minutes acknowledging the customer's feelings. Won't they get impatient?

Some people will, but that's not a good enough reason not to do it. It will save a lot of time in the long run.

20. Seriously, you know what's even dumber than this? Spending a whole hour or two trying to troubleshoot a problem that's not even happening, because you misunderstood the question completely. Happens much more often than you might think.

21. Don't just repeat what they said. Use your own words. If there are gaps in your understanding, it's much easier to discover them this way. Also, you won't sound like a robot, which works in your favor too.

22. Most customers won't know the specific technical lingo of your domain. I know people who still talk about "CD-ROM floppy discs". Help them find more accurate terms for what they're describing, but keep it as simple as possible.

23. If you have no idea what the problem might be, try to guess. Asking them to explain it once again hardly works. They already described it in the best words they could find. It will be much easier for them to tell you which part you got wrong than to reinvent the whole thing.

24. You won't believe how many times I saw what seemed like a very simple problem, summarized it in my own words, asked "is that right?" and got "hahahahah no" in response.

It would be way less funny if we found out that's the case an hour or two later.

25. Narrow down the problem as much as you can, and FOCUS ON SPECIFICS. Find one, concrete example of a situation that went wrong, and make sure you both agree what the desired result should be in that case.

26. I can't stress this enough. This is the difference between cargo cult debugging, and actually solving the problem. Until you have a tangible example of what actually went wrong, you still have no idea what problem you're trying to solve. https://twitter.com/made_in_cosmos/status/1326428200973570048

27. Say someone tells you "Shipping rates in my online shop are too high".

A tangible example in this case will be: "I'm shipping this teddy bear that's 9x9x5in, 1lb, from 90210 CA to 77058 TX. My website says it costs $11.55, but I only paid $7.65 at USPS."

28. Of course, nearly no one will provide all of this information upfront. It's your job to ask for specifics, and to know which specifics to ask for. This comes with practice, unless you're afraid to get your hands dirty and only keep talking about generic abstractions forever.

29. "Shipping rates are too high" can mean a lot of different things, like 2 products charged individually instead of packed together, economy rates disabled in settings, or error in product dimensions. You'll never know which case it is until you find that tangible example.

30. One example is enough at this stage. There will be time to look for patterns later. Some customers will helpfully prime you with patterns they've observed, which might take you down the wrong rabbit hole forever. Focus on the case at hand. https://twitter.com/made_in_cosmos/status/1326421423565500422

31. For now the most important thing is to see the problem with your own eyes. If it's not possible to reproduce it right now, look for historical records, logs, etc. If there's no tangible proof of something going wrong, how would you even know what to do to fix it?

32. There are situations where there's no proof of something ever going wrong, or not enough information to make any sense of it. In that case the best we can do is enable all possible logs and wait for the same problem to happen again. If it doesn't, yay! Good for us.

33. We're 33 replies deep into this thread and only just started thinking about solutions. This isn't by accident. Support is 1/3 listening, 1/3 making sure you understood it right, and only 1/3 problem solving. So are other situations where someone comes to you with a problem.

34. Previously we were looking for 1 tangible example of something that went wrong. In many cases this will be enough information if you know where to look. A surprisingly large class of problems can be boiled down to 'If X then Y', and documented in a searchable FAQ.

35. Personally, I'm most interested in the few random cases that can't be summarized in simple 'if X then Y' rules, where nothing makes sense at all and nobody ever saw this kind of weird error before.

It's like solving puzzles, but better. I love solving puzzles.

36. So when there's a puzzle to solve that no one ever saw before, the next thing we can do is look for patterns. In practice, this means tweaking one thing and seeing if anything changes, then tweaking another one and another one to rule out possible causes of the problem.

37. It's a bit like the scientific process. You form a hypothesis like "could there be something wrong with PayPal?". Then you repeat the same steps again, once for PayPal and once for a different payment method, and then if only the first one fails, you're onto something.

38. As soon as you discover a pattern, see if you can find any counterexamples. Say you just discovered the problem only happens on PayPal orders. Are there any recent orders processed through PayPal that aren't affected by the same problem?

39. We're all hardwired to see patterns. It's inherently pleasurable to discover one. The longer you wait before looking for evidence that might destroy your precious pattern, the more difficult it will be to unsee it.

40. Now the reality is that very few customer support jobs allow the time and space to do all that pattern matching. Usually the first line of support is mostly about tone and speed, and deep troubleshooting requires a few rounds of escalation.

41. Personally I work on a mix of first-line support and weird escalated stuff, and I enjoy the balance between the two. As much as I love solving puzzles, seeing only things broken beyond repair gets exhausting after a while.

42. Once you get a grip on troubleshooting and pattern-matching, the next level is understanding the big picture and scope. Especially in the world of open-source software nearly everything is possible to achieve, but it might be bloody difficult and expensive to configure.

43. Most problems are either due to a bug in code, incorrect options selected in settings, corrupted data (often due to historical bugs that might be solved now), environment config, or the customer trying to use the product in just a bit different way than it was designed for.

44. It is the last category that is most tricky, because everyone believes that their use case is basic, and if your product can't do exactly what they want this is a serious bug that needs to be fixed immediately.

45. There's no easy prescription what to do in situations like this. Only after seeing hundreds of people using the same product you'll know which use cases are basic, what can be reasonably achieved with some neat workaround, and which workarounds aren't worth trying at all.

46. If someone asks you for a unicorn, and all you have is a rhino, don't try to put some makeup on that rhino and make it lose a few pounds and try to convince that person it's almost the same thing. They're gonna find out, sooner or later.

47. Or even worse, they might get to trust you that the rhino is actually a unicorn, and whenever it doesn't behave like one or starts causing troubles, they'll keep coming back to you telling their unicorn is broken, and it will be up to you to fix it, even if it's impossible.

48. So unless you really understand all the tradeoffs involved, it's better to tell the customer that something is impossible than to recommend a hacky workaround that requires 10 manual steps and will make their life miserable. Been there, done that, don't recommend.

49. Of course, saying that something is impossible is one of the hardest things to do in customer support. A lot of people, myself included, chose this job because they love making people happy. Saying no will make them anything but happy. https://twitter.com/made_in_cosmos/status/1313013533936947202

50. Also, when the customer starts the conversation on an angry note, it's relatively easy to believe that it's not about you. But if you just told them you can't do something for them, and then they get angry? Your only job was to make them happy, and you failed at it.

51. This is obviously a very unhelpful way to look at things, but many empathetic people fall into this trap.

It's time for me to get some sleep, tomorrow we'll come back to how to say no with grace and confidence.