The insight and nuance that comes from reading support conversations is second to none but more importantly emphasizing with your user enables you to focus more on building intuitive products.
Everyone should read support emails
91–100 of 214 posts
Re: Everyone should read support emails
#92This is one of my favorite things about Amazon's support system. Support has direct access to PMs, developers, customer facing solutions architects and all of these orgs have close connections to the customers as a result. While not everyone has access to the support cases, customer sentiment is conveyed as part of this process and features or bug fixes are quickly roadmapped as a result of customer pain. The fact th…
This only works if they know how to convey the relevant issues to the right developers properly.
I had some large files on my Amazon Drive (the consumer product) which could never be downloaded via the desktop app, web browser, odrive, or rclone. I had to endure multiple instances of support going through the flowchart, and some promises of conveying my issue to the engineering team only to be met with disappointment.
I never managed to recover those files in the end.
Re: Everyone should read support emails
#93Earlier quoted context omitted.
While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that. I've seen further steps down this road - if there are engineers already answering support emails, then why do we need support people at all. After all, engineers have better knowledge of technical details and can make changes themselves. No need for inter…
The reason lower-tier support personnel are employed is because someone reasoned that the engineers' time is too valuable. If 90 % of incoming support requests will be escalated to developers, it makes little sense to have extra people whose main task is to create SAP tickets or press "forward" in Outlook. Another extra perk of making devs handle the support is that they also have the chance to fix the underlying pro…
Re: Everyone should read support emails
#94This is why we regularly take developers to customers. It is eye-opening to see on-site that your mobile app with tiny but well-designed buttons doesn't work for registering container positions when the user is in a shaky 90 metric tons weighing machine, handling 30 metric ton containers. We write software for container terminal and other logistical actors, and seeing the software being used by real users is so incre…
I think that's valuable, but depends on the organization. At a company I worked at engineering used to go on customer visits, but the "customers" were the executives and managers who make buying decisions and put forth requirements. However, these were not the folks who actually used the product. Their opinion was important (gotta sell it) but it was NOTHING like what we saw in support. The the few times end users we…
Re: Everyone should read support emails
#95"We can't give devs access to support, because [ZenDesk, FreshDesk, etc] costs 9 gazillion dollars per user"
Or use ScopeAI :) (Biased since I work there)
Re: Everyone should read support emails
#96Earlier quoted context omitted.
While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that. I've seen further steps down this road - if there are engineers already answering support emails, then why do we need support people at all. After all, engineers have better knowledge of technical details and can make changes themselves. No need for inter…
> While reading the article, I got a feeling that reading support emails is only one step away from answering support emails - and here you are, suggesting just that. I didn’t get that impression. The article mentioned reading these emails for 30m a week. Going from there to doing tech support yourself as a CTO is... It seems to me that a CTO doing tech support either understand something I really don’t, or really fa…
But the attitude displayed in some of the replies is exactly what I'm talking about when I say some people think support is beneath them.
Re: Everyone should read support emails
#97Terrible idea if people are 'forced' to do it.
Re: Everyone should read support emails
#98Re: Everyone should read support emails
#99The day Bill Gates answered a support call https://blogs.msdn.microsoft.com/oldnewthing/20091123-00/?p=...
>Bill Gates is being taken on a guided tour of the product support department's new office building, and during his visit, he asks one of the people manning the phones, "Mind if I take this call?"
In particular "Mind if I take this call?".
Mind?
The entire idea of the head of a corporation (such as Microsoft in particular) asking permission in that way as if the employee who works for him would have some reason to object or be offended. As if he is butting in front of him in the line at a store or taking his last 10 minutes on a jetski.
Re: Everyone should read support emails
#100At my last job the support team was a thin abstraction layer that seemed to pass almost everything directly through to my dev team. For a while I enjoyed it -- it is satisfying to see how my efforts could directly help customers, undertand how they were using the product, etc. The type of software I was working on meant that technical configuration problems were showstoppers and people hailed me as a hero whenever I stepped in and resolved their issues.
The downsides were insidious and slow to show themselves: lack of time to invest in fixing problems in a systematic way rather than helping customers one-by-one because of time consumed by support, inability to focus on feature work due to support-related interruptions up to 2-3 times per day, the sentiment from leadership that we weren't delivering new features fast enough because of our invisible support labor, the feeling of being "always on" because we had customers with high-urgency tickets around the globe, etc.
After two years of that, I was staring burnout in the face. I told my leadership I didn't want to work this way but nothing changed. When a month went by where I only made 3 commits to source despite feeling overwhelmingly busy I knew something had to change, if not in the org then in myself. I told my manager I simply would not participate in support any more and was deleting Slack from my phone, that if they wanted a good customer experience they needed to make the necessary investments. In my mind this ultimatum was the first step toward quitting my job. But an amazing thing happened once I started putting boundaries in place: leadership started talking about the need for better systems, better documentation, the need to prioritize work that would make the product easier to use and support. My productivity on feature work skyrocketed and my product managers were happy because we were over-delivering for their bosses after under-delivering for so long. I was given a large raise a few months later, the kind people normally have to change jobs to get.
For myself, I learned it's important not to enable dysfunctional process just because I can excel, for a while, in that process. I learned it's important to set boundaries in my work. I learned that focus is sacred and should be protected. If you are a leader in your company thinking about diffusing the support burden, carefully consider the productivity cost to your most expensive/valuable employees that comes with repeated direct exposure to customers.