8 ms·
All Hands Support
- callmeed 16y ago"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.
- mjpizz 16y agointeresting 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 :)
- jeffclark 16y agoSeriously. 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.
- mjpizz 16y agogreat 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?
- sp332 16y agoThe 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?
- brendan 16y agoIn 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.
- sp332 16y agoSo you would, eventually, get around to asking the user to use another browser? Just not as abruptly?
- brendan 16y agoIf 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.
- jeffclark 16y agoWell 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?
- brendan 16y agoThe 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!
- johngalt 16y agoSounds great when you're small, but "All-Hands Support" self-destructs when you try to scale it.
- blahblahblah 16y agoSounds 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.