I find customer support very difficult: everything feels like a personal attack, and I can’t help but get defensive.
How do you, or your team, deal with the emotions of customer support?
L - Listen to understand the issue being presented to you.
A - Acknowledge by showing the customer you understand their grievance by verbally confirming it.
T - Thank them for letting you know about the issue.
T - Take action to resolve the issue. Turn the bad experience into a positive one.
E - Encourage them to return and build loyalty.
Another tip is that you have to separate yourself(mostly your ego) from the objective nature of the request. I build products for a living and when a customer tells me something is garbage or unusable, that can hurt my ego. But there's truth in everyone's perspective. You learn from it, you see the perspective, and you take action to improve it a little more for the next time.
If you remember part of the job is play acting this role, it can actually become fun as you learn more scripts and lines, and you’ll end up making a game of it.
"Good Morning, XXXXSoft, this is XXXX how can I help? :)"
sets a way different tone for the enjoyment of your day than
"Hello, xxxxsoft."
I sometimes use a similar technique to clean/organize my house, and prevent myself from going down the rabbit hole of "what do I do with this stuff?", "I need to list that on eBay", "Oh this is that card I got from so and so I need to write them back", "why do I own all these books??".
I pretend I'm a housecleaner and this isn't really my stuff, and just focus on getting the job done.
Then I can save the existential questions for later, after my house is clean.
In general, a message from a customer is a gift. They may be upset, angry, etc -- but they're giving you a chance, by opening a door to communication. The first thing is to listen, and to understand their perspective. (Hear and empathize.) The second is to acknowledge their concerns. People want to know their concerns are understood. The third task is respond to their concerns. Are you able to address them? If so, let them know what steps you're taking. Finally, always thank people for reaching out.
In terms of the personal side of things; it feels like a personal attack because you care. That's a good thing. On the flip side, it's important to understand that most customers are not at all thinking about you -- they're thinking about their own (often misguided) perspective.
Understanding their perspective can be challenging. You can, and should, make your interactions about them, and not about you. If it feels like a personal attack, then you're likely not seeing things the way they're seeing things. This is a sign that you should focus more on their perspective.
In general, my email format, in terms of responding to customers, is as follows:
> Thank you for getting in touch
> I'm happy to help with [their concern]
> I understand the issue is [the problem they're facing]
> Here's the first thing you can do to solve the issue [propose solution]
> (If there's no solution, give some context, and explain why there is no solution, and let them know you'll take it into consideration for the future)
> Thank you for getting in touch.
> Let me know if you have any questions, or need further assistance. I'm happy to help.
After that... hire someone to do it for you.
If those aren't options:
1. Email only support. Clear expectations on how quickly they can expect a response.
2. Nothing in realtime helps you avoid an overly defensive response and frequently the customer will figure it out on their own
3. Canned responses as much as possible
4. Link to self-service support like help docs so they don't need to reach out next time
5. keep the self-service support updated as new issues come in
6. Create boundaries and rules and stick to them. If someone isn't treating you like a person then cut them loose.
7. Always take the high road. Eventually you will get a weird satisfaction in responding overly nice to the worst of your customers.
Edit: adding 1 more
Create a support email address and direct all customers to use that. If anyone slips into your inbox you just tell them to copy support "for the fastest and best service" next time and then you forward the message to the support inbox.
Then treat that inbox as a separate task from your other duties and get to it when you feel up to it.
Also don't fall down the rabbit hole of feature requests from overly demanding folks. That will kill your business as fast as anything else.
Volunteering to engage with feedback saves you from needing to defend your pride and reassert your value when the feedback arrives. It also puts others on their best behavior and helps them think harder about useful feedback. And finally, it scopes the conversation to a narrow problem solve, rather than an open ended gripe-and-defend session.
To help make that "let me help you do good things with our product" moment work, you can first or also feel out how they feel while you gather the details you need to move forward.
If there's justified anger - if it's clearly something that's broken from the jump, or even a known issue, and it probably shouldn't have shipped broken - you can empathize honestly because we've all interacted with something like this. Sometimes the biggest thing someone on the other end of the call needs is for someone to officially acknowledge that yeah, this sucks.
If there's anger that's not yet justified - something that might be a bug, but might also be user error - make it clear that you're here to help the company fix the problem. If it's user oversight, it's not necessarily the user's problem; the docs could be improved (even if nobody reads them), the UI could be clearer (even if nobody notices the change). People want to know that their problem will result in action, for them, which makes them feel not only value but invested in the product. (This doesn't work as well when there's a new problem every week - in which case, they know they're a tester, and someone should reach out with a discount or be ready to churn them.)
If there's outright panic - if the product is blocking them so critically that their job or a large project is in danger - get the wheels turning on escalation ASAP and make it clear that you're reaching out for help. Nobody wants to be on the phone/in chat/in an email thread with something big on the line and on your end, nobody's taking it as seriously. Even if the end result is user error, or an easy fix, even just hinting that other people are working on it will help. And even if you can only get another person on your side who can't do anything but keep the customer talking while you investigate the issue, it'll prevent long gaps on hold where you might be working your ass off but the customer thinks you're shuffling them off hoping they go away. (If every issue is a panic, they either have a MASSIVE organizational problem on their end that they genuinely need to address to stay a customer, or they're abusing escalations to have you do their job for them. Either way, track escalations closely and sync with others in your company on them as often as you can.)
If you can gauge these things early in the interaction and get the customer closer to being alongside you fixing the problem, then when you tell them "I'm going to work with you until the root cause is identified and fixed for you and everybody else", they're not going to try to see through it as customer service speak.
- Remember that getting honest feedback about your software is one of the hardest things to do. People complaining is feedback. Use that and seek it out!
- Put yourself in their shoes, realize they’re just trying to get something done and they’re frustrated with some feature they expect to have or expect to work a certain way. Sometimes a feature I felt was a differentiator compared to my competition turned out to actually just confuse people and wasn’t the great innovation I thought it was, for the simple reason that I did something differently than how everyone else did it. User complaints can help me understand why my assumptions are wrong. User complaints also help my understand where my documentation is missing or sub-par. Always listen to complaints through the lens of ‘Somehow I led this person here, but they’re upset, so what could I do better for the next person?’
- Always ask them questions! Get as much information as you can out of a user that is engaging with you. Keep the conversation going and get them to tell you their feelings on the rest of your software, not just the broken part. Get them to explain their workflow to you. I was frequently surprised and learned a lot from learning what people were trying to do and how. Ask them about other software they used before they found yours, and why they switched.
- When people are being a little bit mean about the software, respond quickly and kill them with kindness. A huge number of new users to my software seemed to assume they were talking to a bot or emailing the great void. They would be surprised and a little embarrassed when a human responded with de-escalating language to an angry rant. Let them know you’re interested in hearing what they have to say, and you’re interested in fixing the issue they’re having. Give them a reasonable and realistic time frame for when you can fix the problem. (But resist the urge to promise too soon; be diligent about prioritizing accurately and protecting your own time & sanity.)
- Delete and ignore comment by non-paying users who send nasty comments. Ignore most of what free users say anyway. For some reason people who don’t pay have higher and less realistic expectations than paying users. They aren’t invested and they generally seem to be less nice. By all means engage people if they’ll give you useful information, but set the bar high for engaging if they aren’t giving you either money or helpful feedback. Remember that their behavior reflects on them and not you.
Online lists and such are great reminders,[1] but I suggest an in-person class where you can actually do and say things with someone who can provide informed feedback. Look for de-escalation training around you, probably in less expected spaces - I got mine as part of a soccer supporters group, because we'd have to de-escalate drunk fans from crossing lines in the stands.
[1] https://www.crisisprevention.com/Blog/CPI-s-Top-10-De-Escala...
Some people are naturally better at communication than others, and they will definitely do a better job.
Unless you want to learn how to deal with emotions for the sake of personal growth. In that case, check out Stoicism. It is [oversimplified] a philosophy for keeping calm in emotional situations.
Often customers that have had a problem that we fix are the ones that advocate for us the most. They see we are responsive, personable and out in effort to fix their problems.
I am NOT a founder. However, support is a lifeline for startups because it is front line customer feedback. You can offer a meeting with the “founder” and get product feedback and show extra effort.
I am not overly emotional about support but sometimes it is demoralizing. You will get both praise and also frustration. As a founder you at least have the ability to make changes upstream to fix downstream problems and slow the ticket pipeline. THIS IS A LUXURY.
These “personal attacks” have to be considered market feedback. Solving those problems will be the reward and you will get less frustration.
I don't care what they say, how they say it's how wrong (or right) they are or who (if anyone) made a mistake.
I only care about "what is the most helpful thing I can do for this person".
I have apologised, explained internal constraints, identified where our processes have failed, offered video calls, empathised if I felt it would help, however I am mainly looking to "solve the problem this person has" within the limits of my authority.
Look for the facts, ignore the rest, and be helpful and kind.
Also, being sole developer and supporting customers is very hard. I'd be trying to separate me from the software and the customer issues, see them as independent from one another but nevertheless influencing each other (customer issues help you identify what to improve!)
1. See things from customers POV.
2. Maybe you’re not willing to accept what is built is not perfect & have issues. Once you're self aware it will help manage issues better. You need to move from denial to acceptance phase.
3. Our brains are wired to be defensive. Try to acknowledge or trigger whenever you’re defensive. Hard to explain but it’s like anytime you get defensive an inner force tells you YOU ARE BEING DEFENSIVE.
4. Best way to deal with an angry customer is just to agree with them initially, this will calm them a little & from there you can have a more productive conversation.
Good luck!
I built a feature in my program that I thought was a good idea. I was stubborn, took it personally and couldn't see why people didn't see the value in it.
I kept getting support request on discord about it, "how do I disable this ** thing" etc... It's not easy to not take it personally.
Then I took a step back and I saw the feature from the point of view of the user, it made sense that they complained about it, that it was interrupting their workflow and not adding much value.
I decided to stop having it enabled by default.
I've learned over time though that, somewhat paradoxically, these are actually opportunities to create a stronger relationship with a customer than you'd have otherwise. No one likes bugs, but if you show empathy and make it clear that you are prioritizing the issue, 99% of people will be grateful, and will come away with a positive impression. Usually the people who are most upset initially are also the most grateful when the issue gets resolved. Strong emotions are a sign that your product is important to them. They're also going to be the most willing to help you debug, and will report problems that others might ignore.
All that said, you will occasionally encounter people who are pathologically angry, rude, and impossible to satisfy. With these people, you just need to keep in mind that it's about them, not you or your product. Once I realize someone is in this bucket, I remain polite and will fix any issues they encounter as I would with any other customer, but I don't engage with them beyond this. The worst that can happen is you'll lose them as a customer, which won't be much of a loss. It's obviously tougher if they're a big or important customer, but it's still not worth stressing about people like this imo--they could very well still leave even if you indulge all their bs.
The thing that is going to make it difficult for you to teach yourself customer service on the job is that you are the founder so you have no detachment. In order to handle all this you have to be able to detach yourself behind a veil of professionalism and that's WAY easier when you can remind yourself that this is "just a job" and that you are "just representing someone else (the company)" and that this moment is just as much a success for you regardless of the outcome.
None of that is actually true in your case so it's much harder. Hire someone to do customer support if you can afford to, and if you have kids be sure to encourage them to take some random summer job working with the public in high school at least once.
I really hated the fact that we didn't get the needed time to fix problems. I was only allowed to file calls and move on to the next incoming phone call.
Later I became an application manager, and I was basically fixing my own calls (and others' too) and felt 10x better about it.
Not taking stuff too personal is basically what I wasn't good at.
I’d much rather a company says “sorry, your use case is an edge case and not something we support; you could try doing X or Y but what you’re attempting is outside our typical use and not on our roadmap. While we’d love to keep you as a customer I’m not going to make false promises. You might be better off with a tool that specifically enables what you are attempting - or continue using us in the knowledge that this is not possible. Sorry we can’t be more help.”
I leverage that response by trying to make the client feel like I am bringing them closer into the loop. Make getting involved in the suggestion board feel more like an invitation. Let them know of the team that wants to hear from them. If on-boarding is not considered a part of a client's problem-pain calculus, white-glove the sign-up process. Since people have gotten comfortable with video calling, clients have enjoyed getting personal attention from executives in 30-minute qualitative meetings with the product team.
But yes - I imagine too many MBAs is the problem most of the time…
Customer Support is hard for us. Not only the number of OnCalls, but also the complexity of the product causing that we can't solve the problem easily and fast. We are under a lot of pressure.
To solve this, I have tried following ways:
- Build an independent team (may name Escalation Engineering or L3 in other companies, here let's name L3) to focus on the customer problem solving.
- Establish the OnCall duty mechanism, some engineers (maybe 10 one time) must join the L3 for two weeks only focusing on OnCall. Why it is so important, because I believe the quick way to learning our product is from OnCall.
- Get to know our customers better. We are a database product, if we can know our customers' business workloads, we can give them more advices to let the business application run more better in our product.
- Build many Diagnostic tool to solve the OnCall easily.
Finally, I would like to say that although customer support is sometimes painful, it allows us to better understand our customers and know the strengths and weaknesses of our products.
- Fix phone menus so they actually cover my normal, everyday case. Like if I want to report that your service is being used to conduct phishing, don’t make me have an account to do so (looking at you, Microsoft).
- Fix broken links so I can find information.
- Add entries to an FAQ. Have an FAQ. Make it easy to find.
- Fix chatbots so they can cover my question. If you can’t, then have them escalate to a human who is empowered to file tickets that get acted on.
- Don’t lie on your website. “Our chatbot can help you solve the most common problems.” No it fucking can’t.
- Don’t have circular “contact us” flows that ask the user to categorize their issue into an incomplete list of categories which do not cover the user’s case, while never actually allowing the user to “contact us.”
- Try your own services. If you have a phone number on your website, call the number and verify that it actually works. Same with every link on every page of your website. Sign up for email and see if you actually receive email. Don’t assume you will. Do a password reset and see if it works. If there’s a shopping flow, try to buy something. Try to cancel service.
- Don’t overlook the power of clear, crisp writing to help people help themselves. And don’t underestimate the extent to which unclear, ambiguous, confusing writing, or even just imprecise terminology, will be a drag on everyone, both external and internal.
- Make shit work.
I suspect doing these things will have huge bang for the buck toward addressing the issue. If even big companies (Microsoft, Google) can’t get this right, a small company doing better at it will be appreciated.
The detachment that can help - but not remove - that emotional response is to try to change who you represent before you pick up the phone, as much as you can.
When you're developing software, you're representing yourself, more specifically your ideas, plans, and execution. The software is a reflection of how you work.
When you're supporting customers, you're representing the customer. This means the software isn't yours anymore - it's someone else's, something the person you're representing has spent money on but is now in your ear telling you they aren't getting the value they expected.
If you can turn your viewpoint in that direction even a little - roleplay it, change your voice, give yourself an alias, literally put on a different hat, anything that can trick your brain into detaching yourself from your "normal" dev role and emotional attachment - the stress changes.
It doesn't go away, it can't, because you're still YOU. But instead of taking the customer's WORDS as personally, you start to take the customer's PROBLEMS personally. And that doesn't sound like much, but it's an important shift from the problem making you feel SAD to the problem making you feel FRUSTRATED.
It's hard to get past being sad because someone hurt your feelings. It's still hard, but less so, to identify a problem that makes you frustrated, because you can solve problems. You're a developer - you're an engineer, at least on some level. If you can identify a problem, you can solve it, which turns that frustration into motivation. (That sounds cheesy but I can't find less cheesy words right now, I'm pre-coffee.)
Other tips: - get somebody else to help you with support - reserve time for support, like an hour a day at a fixed time - don't leave support cases linger in background. something small can/will become a monster
- Take a systems view. This helps you remember that you and your product are a very small part of that person's life and to remember all the variables that aren't you that might be making the person unpleasant.
- Since you're a solo dev and therefore working for yourself, I presume: It's perfectly acceptable for you to have standards for how you're addressed. One of the benefits to working this way is the ability to say: "I am not comfortable working with someone who is speaking to me this way."
I was once asked to spend some time making sales calls. Not only did I not get any sales, I realized that I was irritating some of the people I was calling. Up until that time, I thought I was a great "people person" (aside from being technically very good). It was very humbling. I don't think I could ever learn to be good at sales: I just (I now know) have no talent for it at all.
Is your customer support by phone, or by email/webform? If it is by phone, then I would suggest switching to email. Also, never respond the emails on first reading. Always read them, walk away, and respond later.
Tbh i'm actually confused what you would see as a personal attack. At the end of the day if someone is aggresive, he's the one having a problem, not you who has a cool product many people use.
Rosenbergs Nonviolent Communications workshop is good, there's a 3 hr youtube, helps a lot.
If a customer is hostile, just sit with them for a minute or two, listen to them ranting, agree with everything they say. They're just venting their emotions, all their points are valid from an emotional point of view.
If they don't turn normal after 3 minutes hand them over to the next operator, have a chain of operators, sometimes someone else just has the better handle.
2) there's also the benefit of adopting the "customer success" mindset: everything you do is intended to help "customers" succeed in some way, and operating from this perspective will make it easier, also
3) some "customers" are not a good fit and need to be "fired", which helps, too.
I'm just here to argue against the "hire someone to do it" suggestions. How your customers feel, especially as a small business, is too important to just hand over to someone else unless you trust them to give you the feedback, both good and bad.
I access customer support email via Fastmail’s web interface. I check it several times a day, but only from my computer (not my phone) and only when I am in the right frame of mind. This helps me a lot.
"If you think about it, isn’t anger the most pointless of the emotions? It’s beastly, isn’t it? When people act in anger, they really are betraying the animal within, all “red in tooth and claw,” as poet Alfred Lord Tennyson put it.
[...]
We have brains that, for the most part, we can control. We’re not just mindlessly going about our day being led astray by impulses that control us. We can learn ethics and have morals to guide our behavior so that we can always remember to never intentionally cause harm or discomfort to others.
We can have a say and make choices about what we experience and how we react. We can use our logic and reason to mitigate the effects of strong emotions in order to have better outcomes for ourselves and those around us."
From: https://moviewise.substack.com/p/a-vow-to-never-get-angry-ag...
Pay someone to do it.
First, I must admit I find it surprising there isn't a support team in between yourself and the clients. Developers are named as such because they develop, they're not support engineers. It's not that developers are cave dwelling trolls that can't talk to people, quite the opposite; it's that you took your job because you wanted to be a developer and develop things.
So my main question is:
1. Are you acting as developer and support? Or is there a Support team in front of you?
If the former, I would strongly suggest to your team about looking to put a support team in front of you. The goal isn't that you never need to deal with cases; quite the opposite! You need to treat cases as the chance to see how people are using your code in ways you never expected and understand if these ways are things you need to account for or not. But, you are not professional services; you aren't on-boarding. You aren't even general support, you're a developer, and your expertise is understanding how the product functions at its core and understanding whether the issue is related to that or more infrastructural, while providing guidance if it's the latter.
If there is a support team in front of you, I think it bears a friendly discussion with your team on the cases being escalated to you. Break it down objectively and get the input from both sides:
1. Why was the case escalated to you by support?
2. Is this a case _you_ think support could have solved? If not, is there something support could have that would have prevented this escalation?
3. Ask the same question of support, and ask them what _they_ wished they had that could have prevented this escalation.
4. Who are the contacts between yourself and support? Can anyone reach out? Is that preferable? Do you find you're spending too much time on non-developer issues?
Focus on these questions and look at it honestly/objectively. The goal here isn't to blame one team or the other, it's to understand where you and your team are missing elements to make your lives easier. A bit of work now will save you all headaches later.
If there _isn't_ a support team between you and the client, what prevents this? Enumerate the items and see how feasible it is to put a small team there to handle the common issues (general config, general infrastructure, etc), and help them to understand the types of issues you want to see.
If you must deal with clients, understand there is always an emotional burden and at the end of the day, most clients just want the product to work without input on their side. You might disagree with such a position, but understand this is what most companies (especially AMERS based) want and expect when it comes to a product with a support offering. Focus on what _you need to feel comfortable with the case__, and explain why you need it. The more honest you can be on the subjects you need more information on, the better.
On the customer emotions, you need to prepare yourself that customers can and will be frustrated for reasons not related to you directly, you're just absorbing their frustration towards a situation. Ignoring it is not a good option as that just suppresses your feelings, but you need to also remind yourself that while they are angry, it's not actually at you, no matter what they write/say. Ultimately, you're dealing with persons who likely aren't great at sorting their emotions and are lashing out due to a frustrating situation. Finding that common point of empathy won't make you feel better necessarily about hostile words, but it will at least help you understand where this is coming from, and understanding is part of the path towards reconciling what you're experiencing.
The above advice comes from my job as literally my job is to deal with the shittiest and worst of customers, and it's extremely emotionally taxing. I won't name company names, but the biggest household names you might imagine basically are run by teams that barely know what they're doing. They have enough money that no one dares question their design choices, and the teams are chosen for cost efficiency not actual efficiency. Questioning this design is a great way to lose a sale/renewal, so outside of the technical team or a moment of epiphany from the client, likely nothing is going to change.
The best option you can do if you must deal with customers is primarily to outline (with brevity but accuracy) what is needed to get to the root cause/solution. The more you can share without beating someone over the head with the deep tech is best. Most customers just want a roadmap; we are at X. We're heading towards Y because of [reason]. Ultimately, we want to get to Z, but we do consider we might need to go to R or S, and include you understanding of the likeliness/why this might be necessary (again with brevity). At worst, this puts the ball in their court and when it comes time to talk to the purchasing powers at the client, it's much easier to maintain "look, we told you what we needed, but your team did not cooperate", and a nice email chain helps this. Summarize all calls with a follow-up email so it's easier to support such positions.
Support is very tough especially for the Western world since so many companies have polluted the space with awful ideas of service, just throwing bodies at a problem to give the illusion of action until a subject owner can be identified. Combine this with the absolutely awful notion that "the customer is always right"†, and it's a recipe for disappointment. The only real answer I see is to be as honest about your path and timeline as you can see. You must prepare yourself that there are individuals who will outright reject anything aside from a "yes sir, I will fix this today" answer, and if that's the case, feel free to be angry about it. I would of course not recommend presenting this to the client and instead stick to brevity and directness about the options, and let a manager step in to handle conversations if the customer is just not willing to cooperate (US Government Contractors are infamous for this...but it's not limited to them of course). Document everything in email as objectively as possible, and make it your mission to avoid finger pointing. If the problem is you suspect networking issue X is affecting operation Y:
Don't write:
"You need to fix X because the current design you have is causing Y"
That is too direct and personal.
Instead, just state:
"Y relies on X and Z. Z is not a factor in this particular issue due to [reasons], so right now the current evidence suggests the problem is related to X. There are a few elements of X that might be related, so I advise check: X1, X2, X3. If you need further assistance on how to confirm these items, please let me know and I can elaborate."
† The reason I dislike this notion so much is that it is the absolute wrong relationship between support and the client. The client's job is _to be wrong_, it's expected and it's nothing to be ashamed of. They don't know information or how systems for a company work, and they should ask. This is normal and expected. The notion that the client's imagination on how something should work must be honored just leads to disappointment as people are incredibly imaginative and can come up with some pretty wild ideas of service that defy physical reality, and trying to capitulate in such a situation is not good service, it's dishonest in my opinion. Support should not entertain fantasies, it should guide to the right solution for a particular issue/need, and discuss that need with the client until there is a meeting of the minds.
So I don't know exactly how you separate yourself from the emotion, that it feels like a personal attack. And the feeling of wanting to defend what you've created. From my experience in the condo, in some cases it might actually be that you are being personally attacked, and to recognize it. I've had an individual use a fake police badge to intimidate my staff from enforcing parking rules, or been sent emails saying that they'll start spreading lies to all my neighbors if I don't do what they want, when they want, how they want it. There is a percentage of the population, I'm going to say 10-15% that just have no clue how to elicit help and have the person actually want to help you. So just recognize that for some it might be the case.
Also, be clear on what workplace harassment is, it's less of a bar than most people think, or those saying, you're doing support, just live with it. If customers are stepping over the line, I think it's important to realize the impact it has on you and take appropriate actions. In condo land, that means getting lawyers involved when there is actual harassment of staff, which fortunately is rare. But we've gotten things like Death Threats over a delivery to the building.
For some actual advice, here are some tactical items I've deployed to try and diffuse tensions in support: - Not everything requires an immediate response. If an email frustrates you and you can recognize it, build a cooling off period. Reply in a couple days. This also helps prevent just arguing back and fourth over email, if the cycle always take a couple of days. This might be harder in software support where you want expectations of quick responses, but if an immediate response affects the quality of the response, it can wait a day, an hour, etc. - Set expectations. If it's a difficult problem and going to take time, don't leave the person on the other end guessing. Tell them the current status of the investigation, and you'll hear from my by end of next week. In condo's, the unit is flooded and the homeowner is living in a hotel. Does the homeowner have reasonable expectations on when they'll be back in their home. The might think everything can be patched in a day, and if they're then left waiting 2 weeks just for contractor bids, they can sit around stewing about how no one does anything. But if you're upfront, we're collecting bids, and will give a status update, it can in some cases diffuse this early. - Some people will try and draw you into an argument, with big long emails with many, many points. You don't need to go through and counter every point. If you're doing that, you might just be having an argument over email. I try to recognize it and not get drawn into it. Just leave the accusatory stuff out of it, and try and steer the conversation back to point, the actual problem that is being reported and address the noise in the most general way possible. - Different cultures do react differently. I don't know if it's the case, but if you have lots of customers in a particular culture group, you might just find them use a lot more force in their messaging, or will do things like never admit when something is their fault. So if you do find this and your customers have a different background then you, might be worth checking out whether there is a cultural boundary between you and your customers. - Repeat problems back in your own words, to make sure you understand the complaint or what the customer is looking for. It's easy to frustrate customers by working on x when they want y. - Try and place yourself in the customers shoes. In software support I did as an example, our product was a flaming piece of poo. So a customer telling me it's a flaming piece of poo didn't catch me off guard, I agreed with them, and could operate with them on a common ground of how do we move forward together and what I'll be doing to fix their problems. - Try and be transparent where possible. If there is direct and indirect causes, the answer isn't we just issued a patch. It's a patch for the exact problem will be available on x, but here's our plan to avoid similar and related issues as well. If you write post mortems, write one that's customer facing and share it. I think lots of customer really appreciate transparency. Even if your causing them heartache.
What none of this addresses is the emotion. You described as a feeling of personal attack and getting defensive. I don't know what's the right answer on that key point, because it's likely a natural reaction. Someone is telling you that the thing you poured your soul into is causing them pain, and you will want to defend what you built. So the important tool to find IMO is the tool that let's you break out of that mindset before responding. That this request is not a personal attack (with exceptions of that ones that actually are), and start thinking of it as your mission to solve the problem the customer has, learn from the complaint, and provide a better product as a result.