I have a lot of thoughts on this as I direct both a support and RND team.<p>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.<p>So my main question is:<p>1. Are you acting as developer and support? Or is there a Support team in front of you?<p>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.<p>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:<p>1. Why was the case escalated to you by support?<p>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?<p>3. Ask the same question of support, and ask them what _they_ wished they had that could have prevented this escalation.<p>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?<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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:<p>Don't write:<p>"You need to fix X because the current design you have is causing Y"<p>That is too direct and personal.<p>Instead, just state:<p>"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."<p>† 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.