Hacker News Reader

Comment by iabacu | Hacker News Reader

When I interviewed at Airbnb, they asked me about one thing I learned in the past that could be useful for Airbnb.

I suggested that people who are developing the product should once in a while spend a few hours handling user tickets themselves (perhaps shadowing an actual customer representative), so that developers get to sense (at the gut level) the pain points.

The interviewer did not seemed pleased with that suggestion.

View on HN

There's an irony here since the CEO of Airbnb, Brian Chesky, used to handle all of the customer service for the company [1].

[1] https://www.stitcher.com/podcast/vox/recode-decode/e/5518597...

dunno if they still do it, but this was normal practice at Etsy when I was an engineer there (2013-2015). Every so often (once a quarter maybe?) I had to spend a day answering support tickets. We discovered (and fixed) a lot of bugs that way.

As a lead developer on some projects, I've explicitly asked to jump into the weeds and handle support.

You can learn SO MUCH about your application just by handling a bit of support. You learn UX issues, you learn what tooling the support people are missing that would allow them to do their job (a simple "send a screenshot to support" button in our app saved our support reps HOURS spending time trying to get customers to describe the problem or teaching them how to take a screenshot on their device).

Not only that, but often the easiest wins are those where you make a happy customer even happier. I saw one customer one time that did this like 10 step process to get some information from the app. They would switch to one user, go to a specific page, open it in a new tab and leave it there, then logout and login to another account, go to their overview page, and then bring the 2 tabs side-by-side to compare numbers.

We already had support for "manager" style accounts that could view info on multiple people, but it didn't have the information they were looking for. A few hours later I had a POC up on our staging system with the information they needed right there, and that person I was talking to became almost an evangelist for our software at their company. Just knowing that they had a problem in the first place was key, and the fix took me a few hours, but it saved them probably that much per week.

I can't imagine a company not mining the info from support for exactly these kind of improvements as a standard operating procedure; it's a gold mine of information, anyone ignoring it doesn't really care about the quality of their product.

One would think so. But here's the problem.

Support (even "in-house" support at global companies) is often outsourced to the lowest bidder. They are paid by support ticket and thus have zero interest in actually resolving the issue once and for all.

It's more profitable to open 20 tickets on the same issue than to actually resolve it.

Also, from the perspective of the call center you're a lousy support person if you actually want to help customers. Your most important metric is calls per time unit. It's in your interest as the support agent to get the customer off the call as quick as possible.

What role were you interviewing for? Also, did they offer you the job?

It was a software engineer role. I did get an offer but in the end I didn’t take it.

>Did not seem pleased with that suggestion.

The interviewer was likely looking for an anodyne coding suggestion, not critical thinking.

Reply on news.ycombinator.com