> I understand how this whole idea got started — customers are the lifeblood of any business. And keeping communication lines open between customers and the entire team is definitely important.
^^ This right here is one example of the article missing the point. It doesn't even have internal consistency - if the devs only spent their first month doing some CS as the article states, then after the first month they don't maintain those supposed open lines of communications.
Thank you. Developers closer to customers can easily fix problems that are generating many of the customer service calls. It also enables them to spot post deployment bugs quickly and keep on top of newly released code.
As someone who has worked at a tech company in support, this is article is misguided. It assumes that all companies are being thoughtless and asking any employee to answer customer support tickets without any training or guidance. We had engineers and product manager answer a few tickets with customer support agents providing guidance. These folks had training and they volunteered to answer tickets for 1 hour/week for a few weeks (with supervision). The engineers and product managers who participated enjoyed the experience because they could see first had the user problems and the language they used. It helped them understand our product not just from the business/product perspective, but from the user perspective. In addition, it allowed them to gain insight into what customer service agents have to deal with on a day to day basis. This led to products being built and launched with customer service in mind. This was a cultural shift and still exists today. Customer service is looped in as product is being built to get help articles and CS agents familiar with how to support new features.
I dunno about the engineers where you work, but a lot of the game programmers at (name witheld, but pick any company. They all seem similar) are not good with interpersonal soft skills. Granted, I didn't read the article before looking at the comments (helps me weed out articles that are a waste of time), but most of our engineers (myself included) would just walk away from the CS role on tilt having learned nothing more than to be grateful they don't have to interact with any people, much less people who have gotten angry enough to contact CS, as a means of making their living. Maybe I'm completely wrong and I just got unlucky with myself and the engineers at the 3 companies I've worked at with programmers, and they really do enjoy confrontational human interactions. I've been wrong before, but the stereotype fits pretty close, though exaggerated, with my experience.
I see a lot of myself in these traits; I don't have the best interpersonal skills. While I don't enjoy confrontation for its own sake, I do enjoy robust debate with my peers so long as it serves a purpose.
However, that in no way precluded me being a consummate professional on support calls. Being nice and polite to your customers isn't difficult, though it can require a bit of patience if they are slow or make mistakes as you talk them through stuff. Or biting your tongue if they are rude or nasty; that's generally due to the frustration the software you wrote caused them. Show them some sympathy! I can't say that I particularly liked doing support calls, but I think pretty much anyone can play the role and do a decent job if they can use some basic common sense when talking to the person at the other end of the phone and keep their cool in the face of an angry caller. If a developer can't handle a routine telephone call in a civilised and respectful manner, I'm not sure I'd want them on my team.
This is really nothing more than a stereotype. You find what you are looking for. There are entirely too many engineers in the world for a generalization like this to be accurate.
>There are entirely too many engineers in the world for a generalization like this to be accurate.
For a generalization to be accurate it doesn't need to apply to everybody in a group, just to a larger percentage of people in the group than in the general population.
It doesn't also need to apply absolutely to each one of the group that it does apply: it just needs to apply more than it does to an average person in the general population.
Yeah. I answered phones and emails for a few years at a B2B software company, and the most I got was a veiled threat that they'd send a formal complaint. In general, abusive customers were were few and far between.
People I know who've worked on B2C support got verbal abuse almost daily.
As someone who has also worked primarily B2B or at least B2(Small Busines) in the technical arena...
In these situations I'd like to remind you that the person you are talking to very likely may be copping that abuse from their customers or managers, and most don't pass it on. So try to help them out, they're literally making your job less miserable :)
> People I know who've worked on B2C support got verbal abuse almost daily.
Is this generally the case? I've answered thousands of customer service queries for my (mostly B2C) startup. I can count on two hands the number of angry/abusive emails I've received.
Yes. In a past life I did phone and email support for two wildly different industries (cellular and banking). I helped train new hires during the first couple of weeks that they answered calls, and several times people broke down in tears during the first few days. Average tenure at one company was only 3-4 months. The other managed close to a year.
I don't know how big your startup is, but I'd hazard a guess that you're small enough for your support to still feel "human." I think this is the biggest issue with most bigco CS.
I know a number of engineers who are extremely socially competent. I also know a lot who fit the description you give. It just depends on who you hire, and what the emphasis is on. Personally, I'd strongly prefer the type that can talk to customers without raging, because it's also their job to understand what users want, and build that.
I know plenty of socially competent programmers who are also good programmers.
However, some people really do associate lacking social skills with technical skills. That sometimes informs company culture - be it by peefering to hire more stereotyped people or by creating culture where unnecessary confrontational style wins the day. In such culture people who have good social skill adjust the way they communicate (full disclosure: I personally did through I am not claiming super superior communication).
I really like that you could volunteer rather than being commanded to do CS. Irrational as it may be that would make a huge difference for me. I'd personally consider volunteering but for some reason I'd resent being ordered to do it.
At MindSpring (an ISP from long ago) everyone was required to listen to 8 hours of live tech support calls every month. I was the lead of the tools team and during one of my call sessions I came up with a feature to our log search tool that reduced our talk times by 20% across the board within a month's time.
I would have never came up with the feature without being on those calls.
I'm a technical lead. I'd rather like to have the opportunity to listen to some support calls as it's not an area that I'm good in. It's never a bad thing to learn what your co-workers might face during their day, even if you think all they do is make your work life harder. The better we know each other and our customers, the better we can help each other to resolve day-to-day problems. If you don't care about your customers problems, you probably shouldn't be making their tools.
I doubt you remember me but I think I worked with you in the IBM building off Luna Road. mindspring was what an ISP should have been during that time. it's nice to see someone else from there on here.
I am just not good at Customer Service. I have no problems helping nice people out and answering questions. I will go out of my way to help people, but the second someone starts to become mean and rude, I will be mean back.
This is not what a company wants. I might end up costing my company a customer because of this. Heck, I even argue with other customers if I see them being rude to the service staff at restaurants and stores I visit.
Her suggestions at the end of the article are pretty good. This will ensure other departments know what's going on.
The biggest failure I see in software these days is software developers who are so far away from their customers that they build the wrong thing. They build what they think is a good idea, and not what the customer actually needs.
We aren't all Steve Jobs, predicting and making the future. Most of us need to instead understand the customer. Working customer support? That's a fantastic way to get to know what your customers want.
Absolutely agreed. In a previous job, I was hired as a developer for a small company and also took most of the service/support calls. It gives a huge amount of insight into how people use the software/hardware, where they get stuck most frequently and also where any bugs lie.
We made most of the changes to the software as a direct result of customer feedback, targetted to the areas which generated the most calls because they caused the most problems for the user. Simple usability/workflow improvements significantly reduced the call volume and made the customers much happier with the software. It also meant that in cases where bugs were found, we could triage them directly on the call or shortly after and in many cases have a tested software update for them during the same working day. When someone runs their business with your product, they greatly appreciate the effort you make to keep their business running smoothly. I learned a lot about our customers' businesses by talking to them, even visted a few in person, and that all helped to make our software serve them better.
I had a few surprised callers when they realised that the tech support and the developers were one and the same; they often expected the tech support to be stupid/less well informed/script-following automatons, and were surprised when we could help them in great detail. Very few of them expected that suggestions for improvement would actually be acted upon, let alone implemented and delivered within a short timeframe. In a small company, with customer numbers in the small hundreds, this led to direct personal working relationships between the end users/customers and the developers, which I found very satisfying. Were we shielded from the customers by first-line support etc., we would have missed out on a lot of very valuable information. Of course, it's difficult to scale this approach, but I do think developers should be well exposed to end users' problems, needs and specific business/domain expertise in whatever type of organisation they are part of, rather than being isolated and disconnected. This is not in any way "insulting" to your team as the original article tries to justify; it's giving your team knowledge and understanding which they would otherwise not have, and getting them directly involved with the use of the software as well as its creation and maintenance.
As someone who's worked a lot in support and has been out of it for a while now, this article utterly misses the point and reeks of whining and excuse-making.
Anyone who's spent time in the support trenches knows that the rest of the company has contempt for them and doesn't know what actually happens on support calls. Getting everyone to do support, at least for a little while, shows what kind of problems support people encounter, both technical and social. Developers in particular see support staff as below them, not equals, and without any CS experience they're often clueless about what goes on in CS - they get a bit more empathic when they've actually seen what happens.
It was actually laughable when the article talked of CS being considered a finely-honed skill that takes years; I can guarantee you, that's not how anyone treats support staff. No-one ever talks of a concept like a "10x support staffer".
In any case, CS is like hospitality: it's an unpleasant job that can be done without much training, isn't well-paid, and few people like it or want to stay in it long-term. It's that unpleasantness which is the real reason why the author doesn't want to do it, not some supposed passion for high-quality CS.
I started in support and do software development now and support is a much harder job in the sense of being stressful and underpaid and under appreciated, but it's a much easier job in the sense of requiring knowledge and skill. I could drop into support again at any time and it would be like riding a bike, but I'd be miserable about it.
Yes and no. That ability to manage own negative emotions, reactions during call and attitudes is something you can get better at - there is learnable aspect to it.
However, it is not perceived as skill worth reward, so people are not inclined to do it.
The worse SaaS are the ones where it's almost impossible to get through to a developer even with a very technical issue. Nearly all SaaS customer service suck! I've dealt with so many this year, I nearly almost have to circumvent the CS reps by finding someone on twitter or emailing security/ceo@. Sure have dedicated CS resps, but I imagine it's whining entitled developers like this that encourage a fear of escalation environment.
Having done both help desk and development I think a taste of support is good for everyone. Of course it must be only a taste. And ideally it would include supervision from support professionals.
Another approach is to have people sit in on support for a brief period to get a snapshot of what it's like and the problems they encounter. Then these observers don't have to fulfill a role they aren't prepared to handle.
Being out of touch with what customers care about is bad for a company.
Being out of touch with what investors want is often good for a company. That's an argument against everybody stepping into the CEO role.
Come to think of it both arguments are the same. The reason you don't want to pay too much attention to investors is because investors are often out of touch with your customer base.
The average company has more customer service representatives than CEOs. That should tell you something about their relative importance to the success of the business.
Having said that, sure, why not? Job shadowing is a great exercise if you do it right.
Ehhh I don't know about this. As a (semi)senior programmer who still takes support calls, either because people call specifically for me or because I have to handle the call, I can't express the value of speaking with end users and clients over the phone. It's just there.
The value is just sitting there, like you're fishing. You just have to catch it and reel it in. If you're willing to work with the person on the other end and talk through the issue, you'll discover countless bits of information that will make your software or product better. Whether it's a workflow you didn't realize existed or a confusion caused by how you worded something or a random bug, the exchange can prove invaluable. You've got someone, most likely in the middle of their day, trying to use your thing, that you've created/sold, and their attention is focused solely on your thing. You have to take these opportunities and squeeze the most out of them!
Look, I get that some protocols like training are lacking and not everyone has the knack for calming people down, but communicating over the phone or via email with customers yields valuable insights and gives you an amazing perspective. If I ever have my own company, every new employee will almost most certainly do a rotation in customer support.
My first experience of direct customer contact was when the call-center rep phoned me and said 'We have no idea what has happened, can you just call the agent and talk about it?'
In the ensuing series of calls we progressed from one of the F-keys not working properly in my application all the way back to discovering that the phone-line into his building had been hit by lightning, damaging various circuits in the office servers and equipment.
I had never heard someone so appreciative of my help, that's when I changed from closing tickets as 'cannot reproduce' to tagging them with 'tell customer to call me on ____'. We found so, so many bugs and broken processes in our applications just by talking to the users.
Customer support is a great experience. Yes, there are users who aren't very technical and can be frustrating. But like many have said, doing support can gian insights into how users use the product, and often enough a bug or two would surface.
I enjoy working with production system (DevOps/SRE). I don't just take tickets from technical users like developers because I build tools and I relay feedback and production issues back to developers, but I also get to talk to end users and also with the business representatives like product owner.
The best out of doing support is actually learning how the product works, if you aren't doing the product development. The aha moment comes when you relay between dev and users.
Companies, especially the technology companies should offer employees diverse training like interpersonal skills and health talks, not just hackathons and technical talks. We work 8 hours a day, 5 days a week, we should free our minds from programming or staring at the computer once in a while. I would take non-technical talk in a heartbeat if offered.
While I agree that it takes good social and interpersonal skills to do support well (as well as empathy, communication etc.), I do think that programmers shouldn't be totally isolated from the people actually using their software.
Many times now, in my own experience, a screen that I thought was designed brilliantly tends to not work as well out in the wild. It is amazing how many visual cues people miss or misread. Sometimes you have to make things more than obvious, and unless you are hearing about it directly from the customer (or better still, watching them do it), then you cannot really understand the challenges they face.
I guess it is the same as making architects live in the houses they design...
Customer service is a very unrewarding job. First, you've to deal with angry customers then you've to explain yourself and get your answers from the developers who again shout at you or call you out on your mistakes.
Developers always consider customer service below them. Working as a customer service rep for even an hour a month will at least make them respect customer service team a bit.
I have a small group, but we instituted a rule that our project manager would handle all customer communications. This was a win in many ways. Our dev team would not be interrupted except for very serious problems, and it actually made our customers feel better when he would tell them he's communicating with the "dev team."
The only thing I didn't like about customer service was being hindered by ass backwards bureaucracy, lazy colleagues without empathy, or outright CRM bugs, to solve the problem. Or to be the first person to actually listen to something that had been fucked up (and documented so poorly) in the last few weeks/month with no fault of the customer. But the customers were awesome for the most part, in some way or another. Either people were lovely; it's amazing how patient and friendly and strong some people can be.. the things I saw (well heard), the odysseys customers went through. Or they and the situation were normal and it was awesome to be friendly to them and give them your best. Or they were assholes and I still learned a lot. I think I liked angry customers I managed to make progress with more than totally benign calls. It wasn't physically or mentally taxing, that is, 99% of the time the stress only ever lasted as long as the call itself at most, and as I said, most of the time I managed to turn stress into something better during the call, and that feels like being a professional lion tamer in a circus run by evil clowns. I went home energized every day. One of my bigger surprises in life, I took the job because I had to, and then stay longer than I had to because I realized "serving" random people sometimes does me good. It also restored a lot of my faith in humanity, I was surprised how cool so many normal people are when you treat them fairly and openly.
I was early at Twilio (roughly #25) and everyone had to do support. I think the threshold was ~20 tickets in your first two weeks. I had every Tuesday for my first six months and went down to one Sunday a month for the next six months until we had a bigger Support team.
Anyway, this article is a mischaracterization of the principle.
Having someone do support is GREAT. It gives them insight into what customers are struggling with, what might be better, how they talk and describe things, and all kinds of related aspects.
Putting new staffers on the front lines is misguided. Just because someone is assigned the ticket doesn't mean someone doesn't review and help refine a response before it goes out.. just like shipping code. Another set of eyes can solve problems, simplify solutions, and make the team better as a whole.
47 comments
[ 2.4 ms ] story [ 90.6 ms ] thread^^ This right here is one example of the article missing the point. It doesn't even have internal consistency - if the devs only spent their first month doing some CS as the article states, then after the first month they don't maintain those supposed open lines of communications.
However, that in no way precluded me being a consummate professional on support calls. Being nice and polite to your customers isn't difficult, though it can require a bit of patience if they are slow or make mistakes as you talk them through stuff. Or biting your tongue if they are rude or nasty; that's generally due to the frustration the software you wrote caused them. Show them some sympathy! I can't say that I particularly liked doing support calls, but I think pretty much anyone can play the role and do a decent job if they can use some basic common sense when talking to the person at the other end of the phone and keep their cool in the face of an angry caller. If a developer can't handle a routine telephone call in a civilised and respectful manner, I'm not sure I'd want them on my team.
For a generalization to be accurate it doesn't need to apply to everybody in a group, just to a larger percentage of people in the group than in the general population.
It doesn't also need to apply absolutely to each one of the group that it does apply: it just needs to apply more than it does to an average person in the general population.
Generalizations are not laws of nature.
People I know who've worked on B2C support got verbal abuse almost daily.
In these situations I'd like to remind you that the person you are talking to very likely may be copping that abuse from their customers or managers, and most don't pass it on. So try to help them out, they're literally making your job less miserable :)
Is this generally the case? I've answered thousands of customer service queries for my (mostly B2C) startup. I can count on two hands the number of angry/abusive emails I've received.
I don't know how big your startup is, but I'd hazard a guess that you're small enough for your support to still feel "human." I think this is the biggest issue with most bigco CS.
However, some people really do associate lacking social skills with technical skills. That sometimes informs company culture - be it by peefering to hire more stereotyped people or by creating culture where unnecessary confrontational style wins the day. In such culture people who have good social skill adjust the way they communicate (full disclosure: I personally did through I am not claiming super superior communication).
I would have never came up with the feature without being on those calls.
I am just not good at Customer Service. I have no problems helping nice people out and answering questions. I will go out of my way to help people, but the second someone starts to become mean and rude, I will be mean back.
This is not what a company wants. I might end up costing my company a customer because of this. Heck, I even argue with other customers if I see them being rude to the service staff at restaurants and stores I visit.
Her suggestions at the end of the article are pretty good. This will ensure other departments know what's going on.
The biggest failure I see in software these days is software developers who are so far away from their customers that they build the wrong thing. They build what they think is a good idea, and not what the customer actually needs.
We aren't all Steve Jobs, predicting and making the future. Most of us need to instead understand the customer. Working customer support? That's a fantastic way to get to know what your customers want.
We made most of the changes to the software as a direct result of customer feedback, targetted to the areas which generated the most calls because they caused the most problems for the user. Simple usability/workflow improvements significantly reduced the call volume and made the customers much happier with the software. It also meant that in cases where bugs were found, we could triage them directly on the call or shortly after and in many cases have a tested software update for them during the same working day. When someone runs their business with your product, they greatly appreciate the effort you make to keep their business running smoothly. I learned a lot about our customers' businesses by talking to them, even visted a few in person, and that all helped to make our software serve them better.
I had a few surprised callers when they realised that the tech support and the developers were one and the same; they often expected the tech support to be stupid/less well informed/script-following automatons, and were surprised when we could help them in great detail. Very few of them expected that suggestions for improvement would actually be acted upon, let alone implemented and delivered within a short timeframe. In a small company, with customer numbers in the small hundreds, this led to direct personal working relationships between the end users/customers and the developers, which I found very satisfying. Were we shielded from the customers by first-line support etc., we would have missed out on a lot of very valuable information. Of course, it's difficult to scale this approach, but I do think developers should be well exposed to end users' problems, needs and specific business/domain expertise in whatever type of organisation they are part of, rather than being isolated and disconnected. This is not in any way "insulting" to your team as the original article tries to justify; it's giving your team knowledge and understanding which they would otherwise not have, and getting them directly involved with the use of the software as well as its creation and maintenance.
That is what good PMs are for (ignoring many customers don't know what they want or change their mind).
Have you guys ever thought about how it feels to have a software dev just dropped in your lap with his boss telling you to put him to work?
Anyone who's spent time in the support trenches knows that the rest of the company has contempt for them and doesn't know what actually happens on support calls. Getting everyone to do support, at least for a little while, shows what kind of problems support people encounter, both technical and social. Developers in particular see support staff as below them, not equals, and without any CS experience they're often clueless about what goes on in CS - they get a bit more empathic when they've actually seen what happens.
It was actually laughable when the article talked of CS being considered a finely-honed skill that takes years; I can guarantee you, that's not how anyone treats support staff. No-one ever talks of a concept like a "10x support staffer".
In any case, CS is like hospitality: it's an unpleasant job that can be done without much training, isn't well-paid, and few people like it or want to stay in it long-term. It's that unpleasantness which is the real reason why the author doesn't want to do it, not some supposed passion for high-quality CS.
However, it is not perceived as skill worth reward, so people are not inclined to do it.
Stop thinking your beyond speaking to customers
2) people are different.
3) some people are better at tech, some better with people
4) if you care about your customer, they should be considered read-only.
5) read-write privileges should be EARNED, probably by experience.
6) generally a csr or acct manager should chaperon or help interactions.
Another approach is to have people sit in on support for a brief period to get a snapshot of what it's like and the problems they encounter. Then these observers don't have to fulfill a role they aren't prepared to handle.
Being out of touch with what investors want is often good for a company. That's an argument against everybody stepping into the CEO role.
Come to think of it both arguments are the same. The reason you don't want to pay too much attention to investors is because investors are often out of touch with your customer base.
Having said that, sure, why not? Job shadowing is a great exercise if you do it right.
The value is just sitting there, like you're fishing. You just have to catch it and reel it in. If you're willing to work with the person on the other end and talk through the issue, you'll discover countless bits of information that will make your software or product better. Whether it's a workflow you didn't realize existed or a confusion caused by how you worded something or a random bug, the exchange can prove invaluable. You've got someone, most likely in the middle of their day, trying to use your thing, that you've created/sold, and their attention is focused solely on your thing. You have to take these opportunities and squeeze the most out of them!
Look, I get that some protocols like training are lacking and not everyone has the knack for calming people down, but communicating over the phone or via email with customers yields valuable insights and gives you an amazing perspective. If I ever have my own company, every new employee will almost most certainly do a rotation in customer support.
My first experience of direct customer contact was when the call-center rep phoned me and said 'We have no idea what has happened, can you just call the agent and talk about it?'
In the ensuing series of calls we progressed from one of the F-keys not working properly in my application all the way back to discovering that the phone-line into his building had been hit by lightning, damaging various circuits in the office servers and equipment.
I had never heard someone so appreciative of my help, that's when I changed from closing tickets as 'cannot reproduce' to tagging them with 'tell customer to call me on ____'. We found so, so many bugs and broken processes in our applications just by talking to the users.
I enjoy working with production system (DevOps/SRE). I don't just take tickets from technical users like developers because I build tools and I relay feedback and production issues back to developers, but I also get to talk to end users and also with the business representatives like product owner.
The best out of doing support is actually learning how the product works, if you aren't doing the product development. The aha moment comes when you relay between dev and users.
Companies, especially the technology companies should offer employees diverse training like interpersonal skills and health talks, not just hackathons and technical talks. We work 8 hours a day, 5 days a week, we should free our minds from programming or staring at the computer once in a while. I would take non-technical talk in a heartbeat if offered.
Many times now, in my own experience, a screen that I thought was designed brilliantly tends to not work as well out in the wild. It is amazing how many visual cues people miss or misread. Sometimes you have to make things more than obvious, and unless you are hearing about it directly from the customer (or better still, watching them do it), then you cannot really understand the challenges they face.
I guess it is the same as making architects live in the houses they design...
Developers always consider customer service below them. Working as a customer service rep for even an hour a month will at least make them respect customer service team a bit.
Anyway, this article is a mischaracterization of the principle.
Having someone do support is GREAT. It gives them insight into what customers are struggling with, what might be better, how they talk and describe things, and all kinds of related aspects.
Putting new staffers on the front lines is misguided. Just because someone is assigned the ticket doesn't mean someone doesn't review and help refine a response before it goes out.. just like shipping code. Another set of eyes can solve problems, simplify solutions, and make the team better as a whole.