All Hands Support(wistia.com)
wistia.com
All Hands Support
http://wistia.com/blog/all-hands-support/
3 comments
Sounds like a terrible idea to me. You're using your most precious (and expensive) human resources to do a task that doesn't require them. Part of the function of ITIL practices in the support team (assuming you're large enough to have a support team) is to notice trends in help desk calls and feature requests, condense that information, and present it to the development team in an organized, coherent manner. If that's not enough to keep your developers grounded in reality, send some of them on site visits once in a while to observe real users trying to do real work with your software.
"All hands support" (provided by engineers) is cool and all, but ONLY IF your product/service is targeted at other engineers or highly technical users (like Wistia and New Relic).
Support for B2C or B2[Brick and Mortar]B services is a different animal, IMO, and one that many startups don't get.
Support for B2C or B2[Brick and Mortar]B services is a different animal, IMO, and one that many startups don't get.
Seriously. If you're not dealing with another engineer/developer/tech-y, you should reconsider having your engineers interact with the public.
Actual entire response from one of our (very smart, social and senior) engineers recently to a customer who couldn't login:
"Hi (customer): I can't recognize the web browser you are using! Can you possibly try to login with one of our supported browsers and let me know if you still have a problem? -(engineer)"
Sure, it's exactly what he needs to know to start fixing the issue, but there's no chance the customer (a florist) is going to know how to respond to that. We're just wired differently.
Actual entire response from one of our (very smart, social and senior) engineers recently to a customer who couldn't login:
"Hi (customer): I can't recognize the web browser you are using! Can you possibly try to login with one of our supported browsers and let me know if you still have a problem? -(engineer)"
Sure, it's exactly what he needs to know to start fixing the issue, but there's no chance the customer (a florist) is going to know how to respond to that. We're just wired differently.
great illustrative story. But couldn't this be more a matter of learning good customer service skills, not a matter of intrinsically being "wired differently" as an engineer vs. non-engineer?
The engineer thinks of the problem as a technical problem with a technical solution: wrong browser, switch browsers. Simple!
Out of curiosity, how would someone with good customer skills handle this situation?
Out of curiosity, how would someone with good customer skills handle this situation?
In my experience, the best response is one in which you make it clear that you personally care about the customer's problem and will do your best to get it resolved quickly. This trumps everything else, so long as it's the truth. If your engineers don't actually care about your customers' problems, then having them do support will only hurt your business.
If it comes down to that, yes. Though I'd first try to track down their requests in the logs and see if it's something we can fix on our end.
Obviously, some companies make a conscious decision not to support all browsers, so there might be no way around it in that case.
Obviously, some companies make a conscious decision not to support all browsers, so there might be no way around it in that case.
So you would, eventually, get around to asking the user to use another browser? Just not as abruptly?
Well sure, that would be ideal.
But as an engineer, are you even remotely interested in learning good customer service skills... or making sure the site doesn't come crashing down in an hour?
But as an engineer, are you even remotely interested in learning good customer service skills... or making sure the site doesn't come crashing down in an hour?
sure, as far as "job responsibilities" go, I agree that keeping the site running trumps answering support emails. That's the primary job of an engineer or ops guy/gal. But hopefully urgent events like this aren't the hour-to-hour norm for a company.
To answer the first half of your question: as an engineer myself, I am personally very invested in good customer service skills. Admittedly, doing a startup (vs. being part of a much larger organization) probably drives my customer interest quite a bit. However, even from an engineering perspective the customer interaction has definitely helped to focus my work on solving real (often recurring) customer pain points and requests, and communicating those back to the customer in a way they understand.
anybody out there with similar experiences as an engineer doing both customer support and development?
To answer the first half of your question: as an engineer myself, I am personally very invested in good customer service skills. Admittedly, doing a startup (vs. being part of a much larger organization) probably drives my customer interest quite a bit. However, even from an engineering perspective the customer interaction has definitely helped to focus my work on solving real (often recurring) customer pain points and requests, and communicating those back to the customer in a way they understand.
anybody out there with similar experiences as an engineer doing both customer support and development?
Totally understandable, especially in a startup area.
This specific case is my day job. We're still startupy-ish, but a little more established (you've definitely heard of us). We have a support team and all that, and the engineers are working on new features and scaling more-so than bug fixes.
I (of course) am working on my own thing and handle 99% of the customer service on it - not only because I want my customers to be happy, but just like you said, I want to work on what really pains my customers.
This specific case is my day job. We're still startupy-ish, but a little more established (you've definitely heard of us). We have a support team and all that, and the engineers are working on new features and scaling more-so than bug fixes.
I (of course) am working on my own thing and handle 99% of the customer service on it - not only because I want my customers to be happy, but just like you said, I want to work on what really pains my customers.
Right on. I'm an engineer (and one of the founders of Wistia), and I really enjoy talking to customers and doing support. I can understand that this type of behavior might not be typical, but it's such a huge advantage to have the people building the product interacting directly with the people who are using/buying it. I love it.
The vast majority of our customers are far from tech savvy. In fact, on the rare occasion where we suggest getting a customer's IT department involved (say, for an email deliverability issue), they often beg us not to -- "IT is too slow, never solves our problems, will want to build their own version of Wistia, etc." I'm always surprised when I hear this, but I guess it means we're doing a good job with the product and support!
interesting point..maybe it's just that the support is best provided by the employees with the "most domain knowledge on product"? In technical startups, these employees happen to be engineers. But in other startups, take for example AirBnB, the most knowledgeable employees might be the ones who have traveled the most.
IMHO, B2C still has some applicability here. It is still beneficial to rotate support among the employees responsible for the final customer-facing product...whether that product is technical or not. Taking a support day periodically to experience your customers' problems firsthand becomes a great way to internalize their most important pain points and desires, so that you can effectively prioritize new products and feature development. Spending quality time with customers can give you a ton of insight into the "whys" and "hows" of what makes them happy :)
IMHO, B2C still has some applicability here. It is still beneficial to rotate support among the employees responsible for the final customer-facing product...whether that product is technical or not. Taking a support day periodically to experience your customers' problems firsthand becomes a great way to internalize their most important pain points and desires, so that you can effectively prioritize new products and feature development. Spending quality time with customers can give you a ton of insight into the "whys" and "hows" of what makes them happy :)
Sounds great when you're small, but "All-Hands Support" self-destructs when you try to scale it.