I created a tool for smaller companies/individual developers that allows users to submit feedback that gets pushed directly into Github issues: https://bugbucket.io/
Everyone should read support emails
151–160 of 214 posts
Re: Everyone should read support emails
#152This 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…
This is what UX Researchers are for.
Re: Everyone should read support emails
#153Now its impossible to email many companies I find. You click on "Contact" and get Twitter, Instagram, Facebook... but not email :(
> Now its impossible to email many companies I find. You click on "Contact" and get Twitter, Instagram, Facebook... but not email :(
I did the website for a nonprofit I set up recently.
From past experience leaving a catchall "contact" email address around, we decided to omit a public email address this time because we didn't want it to be harvested and subscribed to random newsletters.
Re: Everyone should read support emails
#154This 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 one of the ways working at a startup benefited me the most was having to cover the support lines when our support guy was out. I got to interact directly with many customers and learn how they _really_ used the product, what was confusing, what wasn't, etc.
Re: Everyone should read support emails
#155At Re:amaze, we don't hire for customer support personnel. Our culture is that everyone that we currently have on staff, be it engineers, co-founders, marketing - all work on customer support. Granted, we're a small team right now that makes it quite possible to do so, but it really keeps things super lean. We're also a chat and helpdesk platform, so it helps to have everyone use and understand the product.
There's also plenty that can be learned from answering support - from discovering bugs to fixing them to understanding feature requests to satisfying customers (and the joy that you get from a happy customer), that it's our main onboarding tool for our hires across all departments. Sometimes support can take up a couple hours for a team member, but it's totally worth it. Not to mention our customers absolutely love our helpfulness and responsiveness in support and is one of the main reasons we've had plenty of businesses switch over from our competitors.
Re: Everyone should read support emails
#156This 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…
It took me quite a while to unbind the commonly used abstraction of containers with the real objects :P
Re: Everyone should read support emails
#157Hi, Support Engineering Manager here, who has forgone Dev for a career in Support. In a small company ( As companies grow 2 things that I think are really more valuable: - Support Engineers, These are folks that have commit access and can write fixes, who are focused directly on customers. Don't distract product from new features, Support Engineers can fix low hanging bugs, (button states weird/form is weird, error m…
Some caveats and related advice, having been on the product side and two different customer-facing sides: Integrate support engineers at least part-time into the product engineering teams. Support engineers who don't know what product is doing can duplicate or complicate product work. Invest in paying and training the support engineers. Don't pay them well and they'll either transfer to product engineering once they…
I love this extra perspective to my comment!
The only thing I'd add:
> who "have commit access and can write fixes" will invariably introduce new bugs that will block product work.
All fixes by Support Engineers should go through the normal CI pipeline and Code Review process. This is designed to exactly stave off this kind of effect. But yes, I still agree with your points! I love HN <3
Re: Everyone should read support emails
#158Interesting SaaS idea...a company that plugs into whatever CRM you use (Zendesk, Freshdesk, Salesforce, etc.) and automatically compiles a summary of tickets that is sent to certain people or teams within the company.
Re: Everyone should read support emails
#159Most of the support emails are really dumb. Instead of reading product description or help they simply write you email and ask you. 98% of users get through intuitive design. Example1: Customer didn't know how to switch camera back/front and the product used the same icon and approach as Apple. Example2: Customer denied access to camera and asked at support why camera doesn't work.
These sound like legitimate user experience problems. I have fallen into the trap of example 2 at least once, not because I didn't know why the camera didn't work, but I didn't know how to resolve it at the time.
One can't design for 100%. Designing for those 2% simply isn't worth and doesn't bring any cash. PS: user did not read camera access usage description, clicked deny and then asked why it doesn't work. This is pure stupidity.
Re: Everyone should read support emails
#160Earlier quoted context omitted.
This is excellent advice. I will add to it: If in a small company you are spending a certain percentage of time/money/effort on support (probably 10-15%), there is no reason for that percentage to be different in a large company. Go through that again with me, please. You've been spending 10-15% of your time listening to customers and providing good service. When you grow, why would you want to provide worse service?…
An organization with 5 customers can babysit each one to make sure they’re happy in 10-15% of their time. An organization with 1000 customers couldn’t do that even with 100% of their time. The only way to maintain a fixed allocation of customer support funding is to make it less high-touch as you grow.
I respectfully disagree. Note that 10-15% of resources of a 5-customer organization is very different from 10-15% of resources of a 1000-customer organization, assuming your customers actually pay you money (generally recommended).
This means that even assuming you get no benefits of scale (and you should be, your software/product should improve as you learn and support load should fall), there is no reason why you can't provide the same level of support as your organization grows.
The problem is that people assume for some reason that a larger organization can't dedicate 10-15% of their resources to support. This is why whe get crappy support or no way to contact the organization at all.