I often listen in to support calls when I'm on Skype with my business partner (I'm the dev, he's the sales / support / biz owner); this isn't planned, but happens because he's the only one who can take the calls. There isn't a single call I haven't learned something from, or (more positively) haven't had an idea on how to improve the product from. I've also learned a lot of respect for him as someone who not only keeps his cool with a (admittedly!) sometimes grumpy dev, but oftentimes grumpy customers.
Everyone should read support emails
131–140 of 214 posts
Re: Everyone should read support emails
#132How do you prevent this from becoming another stream of continuous disruptions that prevent knowledge workers from having enough sustained, concentrated time to develop big picture solutions? Obviously you want to prioritize work to address what adds value for the customer. But can you really do that if everyone has to be constantly disrupting their work to scan incoming streams of idiosyncratic support requests? Tha…
They have it timeboxed to 30m a week (month?). That should prevent constant interruptions.
It’s not like they’re making everyone true combo support/dev people. Just giving devs an occasional taste.
Re: Everyone should read support emails
#133When I was at Square the design team would shadow support staff to learn about the kind of problems people are facing and more importantly how people talk about your products, i.e. what they call things, how they try to explain what's gone wrong, what they did to solve it or how they ended up with the problem to begin with. It's the closest thing you can come to true realistic user-testing.
That's not just the closest thing to realistic user-testing, production IS the user testing phase :P
Sadly in many companies that’s as close as they’ll ever be allowed to get.
Re: Everyone should read support emails
#134Earlier quoted context omitted.
> Take it one further: everyone should do support, not just read the emails. That's a really fast way to burn out your entire team. Devs don't necessarily have good communication or people skills. They haven't been trained to respond politely when someone sends them a screaming, all-caps e-mail that their product is garbage. That's my job as the Support Engineer.
While that stereotype may be true for some developers, I don't find it holds for most devs I know and work with. People incapable of dealing with emotion probably don't make great employees to begin with.
The emotional response is probably the most egregious that a developer can do, but I stand by my assertion that developers aren't trained in communications. I work with some developers who write amazing code, but if you read their emails, you'd think they were written by a ten year-old. The responses are terse, lack proper punctuation, and usually rife with misspellings. And that's fine: their job is to write code, after all. But it doesn't look good if that raw response goes out to the customer.
Re: Everyone should read support emails
#135Hi, 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…
Can you share anything about what you've seen work as far as collecting and broadcasting experience from support to other teams?
Re: Everyone should read support emails
#136I loved my time at Twilio partly because Jeff made it a point to make sure everyone, no matter their role, understood what was happening in support. Many engineers, product managers, and even sales people would take support tickets to get a better understanding about what the customers were struggling with.
Every company needs to do more to understand what the customers are struggling with and the easiest way to do that is to get on the front lines.
Re: Everyone should read support emails
#137Earlier quoted context omitted.
My most recent job the head of the company had a great comment. One of the first things he told me "Our end users are not smart, no matter what anyone tells you. They can barely use a computer. Remember that." He wasn't wrong ;)
I HATE that attitude. It may occasionally be right (depends on your product/intended use) but it was the catch all ‘do as I say’ excuse one of the executives used at a previous job. Have a suggestion on how something could be done better? Your way is too complicated and our users are dumb as posts. So we can’t do it. It’s not worth even thinking about. Of course if THEY want to do the complicated hard to understand t…
>Why do the job if you have actual contempt for your users?
It's not contempt, it's understanding who is at the end of the keyboard.
In this case our customers are fairly capable, but the software is really for their end customers who are in a niche industry that is AMAZINGLY behind the times in terms of technology, and the people they hire who actually end up doing a lot of interacting with the software are honestly barely high school grads and are surprisingly incapable / startled by anything out of a very specific routine.
Re: Everyone should read support emails
#138Hi, 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…
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?
And yet, this seems to be the established thinking (oh, we can't possibly provide direct E-mail support at this scale, let's hide our contact information and make customers jump through hoops just to contact us, and let's keep our support team small so that we can make more money).
Your customers will report lots of issues, and yes, some will be bogus. But most will point to real problems, either with your software, your hardware, your usability, your processes/procedures, or the limitations of any of the above. If people write to you, it means they took efforts to contact you: do not just discard their reports as "bogus".
Another way to look at this is that every bug report is worth its weight in gold, because for every customer who reports a bug, there are 10 others who do not, and just stop using your app/service/whatever.
Also, if you ever extend/automate/scale your support, make really really sure that there is ALWAYS a way for at least some user reports to make their way to developers, designers and architects. Otherwise many valid bug reports will get stonewalled and lost. See the recent Apple FaceTime ("facepalm") fiasco for a good example of this.
Re: Everyone should read support emails
#139Hi, 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…
as someone who did support for years and now does engineering I think this is so correct. Support is listening to customers, not only that they are listening to a LOT.
I think it's valuable for engineers to talk to customers but they and product should also actually listen to support - they are probably telling you a large majority of the pain points your customers are experiencing.
also - and another major thing - make sure you have a way for support folks to become engineers, product managers, designers, etc... in my (clearly biased) opinion this often results in an engineering / product department with a deep understanding of your customers needs in its bones
Re: Everyone should read support emails
#140Hi, 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…
Can you share anything about what you've seen work as far as collecting and broadcasting experience from support to other teams?
1. Invite support to product/eng meetings where you are prioritizing. Add them to the agenda by default so it's natural to expect them to speak. This is huge and helpful.
2. Consider baking in "Support gets a MINIMUM of X things" on priority. Tough conversations will be had, but support/product/engineering will learn how to get what each other need. This one falls apart and "when the going gets tough". Support gets the short end of the stick usually. (That's why I advocate for a Support Engineer, so those things don't even need to leave support, they just get fixed and when support speaks, the teams know it's big.)
3. Make sure whomever is heading support knows what other stakeholders need to see, so they can deliver. Some would call this "data driven" but in some orgs, "data" is just 3 angry users.
4. We currently use this term "Stable Counterparts" and that's vital, figure out who should regularly be talking to support and about what, and once that relationship forms, things get smoother. Until then, support will be yelling into a void.