
Don't Make Everyone Do Customer Service (2015) - mooreds
https://lauraroeder.com/stop-insulting-your-team-by-making-everyone-do-customer-service-7a7aa3370c68
======
djchung23
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.

~~~
UnpossibleJim
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.

~~~
foota
There's a world of difference between being customer support in the b2c space
versus b2b imo.

~~~
icebraining
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.

~~~
gnicholas
> _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.

~~~
Merad
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.

------
snake_plissken
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.

~~~
dingaling
Absolutely!

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.

------
mabbo
How short sighted.

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.

~~~
rleigh
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.

------
cowmix
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.

~~~
scaryclam
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.

------
dang
I've long dreamt of having a company where there is only one job title and it
is "Customer Service Representative".

~~~
mulmen
It's amazing how radical that idea is.

------
vacri
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.

~~~
empath75
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.

~~~
watwut
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.

------
paulryanrogers
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.

------
cyberferret
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...

------
musage
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.

------
caseysoftware
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.

------
yeukhon
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.

------
cabaalis
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."

------
jimjimjim
1) always good to have devs close 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.

------
torrinson
This is a pretty good article.

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.

------
sitepodmatt
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.

Stop thinking your beyond speaking to customers

------
CoreXtreme
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.

------
bitL
Alright, why not make everyone play role of CEO 1h/week then? Any arguments
against it?

~~~
mulmen
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.

------
ApolloRising
Article completely misses the point

~~~
brett40324
Why, and what's the point they're missing? It's their article. They honed
their point, not what point you think is the point they missed.

~~~
vacri
> _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.

~~~
ApolloRising
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.

