Live data from Hacker News

Everyone should read support emails

medium.com

191–200 of 214 posts

Re: Everyone should read support emails

#191
post #150

Earlier quoted context omitted.

Seconding MBCook here; I believe this advice is nonsense. Truth is, most people are smart enough. If this is a product for internal use, then they might be also extremely motivated, as it happens when handling some piece of software becomes a key element of keeping a job. Taking the approach of "our users are dumb" makes sense only when you're not thinking about providing value for those users, and instead you're wor…

>Truth is, most people are smart enough I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.

> It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should

That's a managerial problem not a technical one, so any technical solution like dumbing down the user interface will almost certainly fail.

Re: Everyone should read support emails

#192
post #69
post #52

Earlier quoted context omitted.

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…

At the last company I worked at they brought glad handers to take care of the execs while I the "low level tech" went around to people's cubes and spent 2-3 days talking to them, understanding their requirements (usually with NO meetings, just 1-1 after talking with their managers and leads.) This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave ab…

At one previous employer, I got into some heat for being that "low level tech" that went directly to users' cubes and talking to them directly instead of waiting for stuff to filter up and then back down chains of command. The users were really excited to see some features they had needed for years finally implemented and all it cost them was buying a bored college intern lunch a couple times. The managers were so unhappy with me though for breaking protocol.

That job taught me a lot about what to avoid in a corporate culture, because of how dysfunctional that was that the more actual work I did the worse my reviews got and the more my managers seemed to hate/resent me being on the project. It was a situation I hope never to repeat in my career.

Re: Everyone should read support emails

#193
post #69

Earlier quoted context omitted.

At the last company I worked at they brought glad handers to take care of the execs while I the "low level tech" went around to people's cubes and spent 2-3 days talking to them, understanding their requirements (usually with NO meetings, just 1-1 after talking with their managers and leads.) This got me the best feedback I have ever gotten, and I regularly implemented fixes and changes that made the C-levels rave ab…

At one previous employer, I got into some heat for being that "low level tech" that went directly to users' cubes and talking to them directly instead of waiting for stuff to filter up and then back down chains of command. The users were really excited to see some features they had needed for years finally implemented and all it cost them was buying a bored college intern lunch a couple times. The managers were so un…

Yeah, going directly to the end user is almost certainly best. The amount of times you find people spend 2 hours of their days on what would be literally a 5 minute fix (my favourite being the select with a thousand options that wasn’t alphabetically sorted) is mind blowing.

And all that just to preserve some egos. Though to be fair, in some cases users do request crazy stuff, you just shouldn’t listen to them and look at what they actually do.

Re: Everyone should read support emails

#194
post #121

Earlier quoted context omitted.

I HATE that attitude. It may occasionally be right (depends on your product/intended use) but it was the catch all ‘do as I say’ excuse one of the executives used at a previous job. Have a suggestion on how something could be done better? Your way is too complicated and our users are dumb as posts. So we can’t do it. It’s not worth even thinking about. Of course if THEY want to do the complicated hard to understand t…

> Why do the job if you have actual contempt for your users? To... To get paid, isn't that obvious? Sometimes you have to do what you have to do.

I mean, yes, in retail or the service industry, but it should be possible to find a job in IT where you can at least tolerate the end users (or just never see them altogether).

Re: Everyone should read support emails

#195
post #181

Earlier quoted context omitted.

This is all about scaling. You want to do 10x the customers with 2x the employees, so that the business finally starts to make money. The service level that took 10-15% of your resources back then would take the majority of your resources now; the same % of your resources now is much less hours per customer.

But that's my point, isn't it? If you want to do 10x the customers with 2x the employees, you will be cutting into your support resources, and your customers will suffer. This is exactly why we (as customers) all have to suffer bad or no support. And sadly, we put up with it, mostly.

There are serious overhead costs to running a company 10 times as large. If you also have to hire 10x the employees, you'll end up needing to charge more than most customers are willing to pay. (Customers who are willing to pay out the nose generally do get good customer service, even from organizations that are normally bad at it, up to and including teams of engineers deployed to the customer's office to help out.)

Re: Everyone should read support emails

#196
post #191
post #150

Earlier quoted context omitted.

>Truth is, most people are smart enough I agree, if we assume they're going to try. It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should. It's not fair, but if they're not going to try, they're still the person behind the keyboard.

> It's not a perfect world and IMO most people really aren't trying / putting in the effort on the things we think they should That's a managerial problem not a technical one, so any technical solution like dumbing down the user interface will almost certainly fail.

If your user interface is so simple that understanding it doesn’t take any effort at all, that’s a pretty great thing.

I imagine the hypothetical lazy user thinking ‘I cannot figure out a way to convince my boss that I do not understand this UI...’

Re: Everyone should read support emails

#197

This 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…

shaky 90 metric tons weighing machine, handling 30 metric ton containers Also gives an immediate answer to all these "should we fail gracefully or crash loudly?" arguments.

Yeah, that sounds like the most fun place to crash loudly ever.

Just a small failsafe to ensure nobody is nearby.

Re: Everyone should read support emails

#198
post #168

Earlier quoted context omitted.

This is all about scaling. You want to do 10x the customers with 2x the employees, so that the business finally starts to make money. The service level that took 10-15% of your resources back then would take the majority of your resources now; the same % of your resources now is much less hours per customer.

There shouldn't be a linear increase in support requests with a larger customer base. As your product scales to more customers, the percentage of support requests generated should be going down as you improve your product and support documentation based on existing customer support requests.

The number of requests may scale linearly, but the number of actual issues won’t.

Re: Everyone should read support emails

#199
post #26

Earlier 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…

Best way to make me improve software is to force me to use it.

Re: Everyone should read support emails

#200
post #180

At Basecamp, everyone in the company does a workday in support every month or two. It's a fascinating experience to take part in: https://github.com/basecamp/handbook/blob/master/our-rituals...

I worked on a software project for 10 years where we did this, with 5-25 developers in the rotation over time (we grew). It was unpopular with many of them, but I loved it, and found it incredibly valuable. Even the people who thought it was useful learned valuable context they didn't realize they learned (e.g., how helpful our own documentation was when they needed it).

I really like the idea of doing a day of support a month. When I did it every day of the week it drove me crazy and made me really cynical though.
Post reply on HN