I worked at a SaaS startup that did this, and found pretty similar benefit: quicker fixes, and a better understanding of real customer needs.
Eventually we made it optional though, because we found that a minority of our developers really disliked it. Which I can understand- not everyone enjoys interacting with customers and answering dumb questions like "can you reset my password?"
I personally found it really valuable, though. After the hundredth password reset request, I was pretty motivated to make our password reset function easier to find. :)
Some pitfalls to be aware of, though:
1. This only works when the people doing support feel empowered to improve things, either because they can do it themselves or because they feel they are listened to by whoever can. For example, I can say to our founder over lunch: "People have been complaining about X a bunch this morning. How about we do Y to address that?" Then we'd discuss it, and I could build it that afternoon. For smaller fixes, it was often just posting on our group chat: "Hey, I'm fixing A by changing B" and merging it if no one objected.
Without this ability, though, it could easily get frustrating. If you're being forced to deal with repeated customer issues you have no power to address, it can feel more and more like an unproductive burden.
2. It can have trouble scaling with the complexity of your product. We were targeting small businesses when I started, and I was able to answer most questions about our product by myself. As we got bigger, though, and started introducing more complicated features aimed at the needs of larger companies, there were more and more features that I didn't have a solid grasp on. I probably could have kept the whole product in my head a lot longer if I were a full-time support worker, but as a dev I only did 5-10 emails per day,a nd didn't have the time to devote to learning some of the more esoteric aspects of our product.
3. Not everyone is cut out for customer service. We tried to hire good developers with personalities we wanted to work with. That often, but not always, overlapped with the type of communication skills necessary to be an effective support person. We had a few developers who lacked the patience to deal with slower customers, or weren't really good at explaining things clearly to them.
Yep. I worked tech support part time in college- I remember. :)
When implementing an "everyone does tech support" system, though, remember that at least some of your employees won't have much trouble leaving if they find themselves hating the experience. When they have to deal with customer complaints, but can't do anything to fix them, they may well move to a company where that's not the case.
I think #1 is a feature, though. One of the ways a growing company can go bad is to make it hard for most people to solve customer problems.
The megacorp customer support model is basically just to put all the disempowered support people in Nowheresville, so that nobody "important" knows how much the customer experience sucks. Which is part of what allows startups to come in and savage their business.
But there's another path: you can also avoid the customer and staff frustration by empowering them to fix problems, and working hard to keep it that way as the company grows.
Eventually we made it optional though, because we found that a minority of our developers really disliked it. Which I can understand- not everyone enjoys interacting with customers and answering dumb questions like "can you reset my password?"
I personally found it really valuable, though. After the hundredth password reset request, I was pretty motivated to make our password reset function easier to find. :)
Some pitfalls to be aware of, though:
1. This only works when the people doing support feel empowered to improve things, either because they can do it themselves or because they feel they are listened to by whoever can. For example, I can say to our founder over lunch: "People have been complaining about X a bunch this morning. How about we do Y to address that?" Then we'd discuss it, and I could build it that afternoon. For smaller fixes, it was often just posting on our group chat: "Hey, I'm fixing A by changing B" and merging it if no one objected.
Without this ability, though, it could easily get frustrating. If you're being forced to deal with repeated customer issues you have no power to address, it can feel more and more like an unproductive burden.
2. It can have trouble scaling with the complexity of your product. We were targeting small businesses when I started, and I was able to answer most questions about our product by myself. As we got bigger, though, and started introducing more complicated features aimed at the needs of larger companies, there were more and more features that I didn't have a solid grasp on. I probably could have kept the whole product in my head a lot longer if I were a full-time support worker, but as a dev I only did 5-10 emails per day,a nd didn't have the time to devote to learning some of the more esoteric aspects of our product.
3. Not everyone is cut out for customer service. We tried to hire good developers with personalities we wanted to work with. That often, but not always, overlapped with the type of communication skills necessary to be an effective support person. We had a few developers who lacked the patience to deal with slower customers, or weren't really good at explaining things clearly to them.