Everyone should read support emails • Hacker News Board

Re: Everyone should read support emails

#51

Post by tgtweak » Mon, Mar 04, 2019, 2:12 PM UTC

If a user is willing to message you, you can be sure many hundred other users are thinking/experiencing the same thing.

I remember support commenting that lots of users seemed concerned about security (messaging to ask if their files are kept after) and we were removing them, plus it was written in the privacy and terms page.

Finally we put in plain writing that we didn't keep any files, right on the landing page... 40% lift in conversions.

Support is a better signal than exit surveys.

Re: Everyone should read support emails

#52

Post by duxup » Mon, Mar 04, 2019, 2:14 PM UTC

superice wrote: post #43

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…

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 were there, they clearly did not give their honest opinion in front of their bosses. And really even folks giving feedback who use a product are poor at doing son.

But support is where the rubber hits the road and folks actually encounter real issues that they can't solve on their own and create real pain points that will come up.

In my example there were still a lot of issues we'd take back to engineering and they'd say something that amounted to "but they said they don't use it that way" and it was a real chore to get engineering to understand the difference between what an executive asks for / some of the requirements they were given, and what the real user does / needs / asks for. Understandably engineering resources were sometimes irked by this, and support often took the hit politically because of it. It was one of the reasons I got out of support despite getting along with the engineering teams really well.

Re: Everyone should read support emails

#53

Post by iagovar » Mon, Mar 04, 2019, 2:14 PM UTC

mrhappyunhappy wrote: post #25

As a user experience designer the first thing I ask for is access to any and all data available, including support chat system and access to support folks so I can quickly gauge the general level of issues being experienced. It’s just one way to identify possible issues, far in advance of jumping to make any UI changes.

> and access to support folks

This is key. Support people is the ones that talk with customers, and know what's going on. Their experience is key.

In most companies this people is low-pay look-down people, gets tired quickly etc.

Re: Everyone should read support emails

#54

Post by duxup » Mon, Mar 04, 2019, 2:17 PM UTC

jdorfman wrote: post #50

I started my career in technical support and looking back it was one of the greatest learning experiences. The Support Team knows the product better than anyone in the company which is extremely valuable if/when you get promoted to another position within the company.

I did the same. Worked in support, moved on to web development. It teaches you so much about understanding and communicating with customers.

I had some conversations recently where I offered my opinion.

"I think this might be a bit complex for the given users who are using this."

"But they want all this information, we're doing it."

A few weeks later end customers are all confused and they're up in arms because they can't figure out how things work because the product threw the kitchen sink at them on one or two pages...

Re: Everyone should read support emails

#55

Post by superice » Mon, Mar 04, 2019, 2:18 PM UTC

duxup wrote: post #52

superice wrote: post #43

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…

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…

Yeah, absolutely, we see that all the time as well. We have the benefit that usually we only have to do sales at the executive level, and for everything else we deal with the operations people, which means that if we go for an on-site visit we usually won't meet higher management than operational team leads.

We learned that what executives say and what operation does is not the same thing, which is why we sell our software we say: "We'll fix your problems, but be warned: we won't do it your way", and as long as that expectation is maintained we have very happy customers.

Re: Everyone should read support emails

#56

Post by ThomPete » Mon, Mar 04, 2019, 2:18 PM UTC

When I was at Square the design team would shadow support staff to learn about the kind of problems people are facing and more importantly how people talk about your products, i.e. what they call things, how they try to explain what's gone wrong, what they did to solve it or how they ended up with the problem to begin with.

It's the closest thing you can come to true realistic user-testing.

Re: Everyone should read support emails

#57

Post by AnIdiotOnTheNet » Mon, Mar 04, 2019, 2:23 PM UTC

badsectoracula wrote: post #37

AnIdiotOnTheNet wrote: post #20

Earlier quoted context omitted.

> In my experience, such time pressure comes from management In my experience, open source developers are just as bad, if not worse, when it comes to their treatment of users.

Yes, but open source developers are in their vast majority unpaid volunteers gifting their labor to other users, so these users can either accept the gift as it is or not accept and move on. They are not entitled to other people's work and time for free.

Point is: even absent management pressure developers choose not to care about users.

Re: Everyone should read support emails

#58

Post by chapium » Mon, Mar 04, 2019, 2:23 PM UTC

scrollaway wrote: post #9

Fully agreed. I'll go a bit further: Everyone, especially engineers and PMs , should once in a while actually reply to support emails. As CTO of my previous company, I still found time for large amounts of customer support, and so did one of my cofounders. It's definitely important IMO for key people to be in contact with the userbase. Get a better look at what people are asking for, feel more directly responsible fo…

I'd like to add, shadow your customers a year after deploying your product. Engineers often blame the user, but users often end up using peculiar workflows to get around ui issues in your app, specific bugs, or other issues. Also if the user doesn't understand part of your product a year later, you probably should be improving that experience Either within the app or externally by improving documentation and providing training.

After some burn in time, is it really the user who is doing something dumb?

Re: Everyone should read support emails

#59

Post by zerkten » Mon, Mar 04, 2019, 2:25 PM UTC

duxup wrote: post #52

superice wrote: post #43

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…

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…

Is this a question of redesigning your visits to incorporate your real stakeholders? There are many companies with management and workers at polar opposites like this. I've seen this tackled by proposing that you offer some on-site support sessions and bring support and engineering along for the event.

Focus on making management at the company feel like they are doing something for their deployment and get more forthright feedback because they can't be in as much control. Establish some direct follow ups, if needed, to primarily tackle the support issues, but ensure the folks who were on-site are part of that conversation. Present a summary of the event back, including action items which you take from the event alongside their pet problems/requests.

Re: Everyone should read support emails

#60

Post by robbiemitchell » Mon, Mar 04, 2019, 2:25 PM UTC

Agree 100%. The trouble is, you can't ask everyone to read everything, and it's not always affordable or even possible to give everyone access to the data. Our goal at frame.ai is to help you understand and act on your chats and emails -- everywhere they happen -- by drawing your attention to the conversations that warrant it.

Data are normalized and unified from sources including Zendesk, Intercom, Slack, and Service Cloud. Destinations include manual export, with triggered alert and warehouse sync under development.

In the middle is a layer of enrichment and search-based dashboard prototyping. Enrichment includes "sentiment moments" (wins, issues, risks), conversation cleanup via elastic tagging, and auto-tagging. You can see a peek at some of our research in this area at this blog post: https://blog.frame.ai/learning-more-with-less-1e618a5aa160

Importantly, there's no per-seat charge. We think everyone in the company who can have access should be able to explore customer conversations, visualize them, and export for further analysis and presentation.