

Today I gave the wrong answer to a customer - jennita
http://carokopp.com/post/48015412277/today-i-gave-the-wrong-answer-to-a-customer

======
lobotryas
The author seems to be missing how disruptive interruptions can be to some
developers.

The "on call" idea might have some merit because it allows the developer to
adjust their coding schedule around the X hours they will lose every day for a
given period of time with customer assistance.

The "all hands" idea sounds terrible. Asking a developer is asked to answer 5
customer emails daily, each one needing a variable length of time to respond
to, threatens to poison the well and become a burden. My understanding is that
a developer would either try to answer the emails at the very beginning or at
the very end of the day to keep distractions at a minimum.

My biggest question is - what is the reason for the author to have this many
questions after being with Buffer for over 8 months? This seems like
sufficient time to learn all the ins and outs of most products. Moreover, I
hope that Buffer dev new-hires are told that they'll be asked to wear many
hats, including the responsibility for customer support, as part of the
regular duties.

~~~
adrianhoward
_The "all hands" idea sounds terrible. Asking a developer is asked to answer 5
customer emails daily, each one needing a variable length of time to respond
to, threatens to poison the well and become a burden. My understanding is that
a developer would either try to answer the emails at the very beginning or at
the very end of the day to keep distractions at a minimum._

I've seen this sort of setup work very well. It's something I've done myself
(while wearing a dev hat) and found it very useful. I'd happily do it again.

Yes - being interrupted at any time would be a pain - but...

1) There are normally enough natural pauses during the day where knocking off
a few customer support issues is doable. It can actually be quite a nice
change of pace. It uses a separate bit of your head and you come back to that
problem that just stumped you fresh after the break.

2) It's can be a mistake to worry about the productivity of individuals and
neglect the productivity of the company as a whole. Slowing me down
individually can make the company as a whole run faster.

3) It gets you direct contact with actual customers on a regular basis. This
is pure f __king gold. Lost count of the number of times this has produced
insights about how the ongoing development should work. That minor annoyance
that three folk mention in a row that's _sounds_ tricky but is a 2m fix.

~~~
bartl
Re (1): I am a developer. I do several different things a day. It's an ideal
moment, do do 1 short thing in between 2 different long tasks. It's a nice
distraction, a time to empty your head.

So, unless you're spending your whole day on one single huge feature all day,
there are plenty of opportunities for short breaks.

But I agree that having interruptions at random times may be
counterproductive.

------
choult
Rotating "on call" around sprint cycles, for example, has a lot of potential
IMO; as engineers we need to have not only a solid understanding of our
product and technology but also of our customers - how can we build the best
product for them without having some empathy with them?

One of the greatest joys for me in my day to day job is problem solving for
customers and colleagues. The satisfaction I get from helping someone is
almost second to none; there's also the added benefit of the customer feeling
valued and the company coming off as one with great service. Another part of
the interactions is honesty; explaining what an issue is to a customer or
colleague makes them feel cared about as well, and builds a lot of trust. That
relationship can really help you get through tough times; a happy, helped
customer is a loyal one. I've had one or two customers at a past employer who
have said that I was the only reason they didn't drop us.

Having said that, it can be a huge time-sink and I wouldn't recommend mixing
"support" with "feature" work; inbound communication is highly disruptive to
concentration, impossible to estimate and if there's a lot of it it can
overwhelm a developer to the point where they don't get feature work done and
will, I guarantee, start feeling crap about it.

I would personally advocate a "Business As Usual" team working in a Kanban
style to handle piecemeal support and technical issues, with perhaps a small,
non-critical feature project bubbling in the background, balanced with feature
teams working in sprints, with a healthy team rotation; it will keep your
engineers fresh, interested and engaged with customers and the product.

/my 2c

~~~
LouDog
Head of Support in the AdTech space here. Rotating Devs into the Support-Team
is exactly what we do. The QuiRe – for QuickResponse – leaves his Feature-Team
for the 2-week sprint period and gives helping hands to Support-Staff. As
DevOps belongs to this team as well, the QuiRe can hack on small DevOps issues
in the spare time. Brings in some nice knowledge distribution as well...

~~~
jennita
So cool to hear this. We're trying something similar with the entire staff at
SEOmoz. Everyone knows the product in different ways and takes turns as part
of the "Help" team. It's a new concept but great to hear how others are doing
it.

------
chris_wot
This post seems sincere, but insecure. I'm a bit concerned that someone in
support needs to ask so many questions...

This is where a queue of support tickets and a knowledge base would really
help out I suspect.

~~~
jennita
Totally agree. I do think though that right now the Buffer App team is pretty
small and slowly growing. Plus when a product is constantly changing or
getting upgraded, it can be difficult to know all the answers all the time.

I do feel this post is pretty sincere and I liked the fact that she was honest
with her mistake.

------
ThisIsADogHello
So basically, when somebody asks you a question, it's better to answer it
truthfully and possibly do some research on the answer, rather than just make
up a bad answer?

~~~
chris_wot
It sounds like pressure to give an answer very quickly. Just answer it later!

~~~
jonathanjaeger
Agreed. I also don't think there's any problem to respond right away saying
you will investigate the issue with a developer that day and get back to them.
That way you satisfy the need to respond quickly so the customer knows "you're
on it" while also being able to give a valuable answer sometime in the very
near future.

~~~
jennita
I manage the Community team at SEOmoz, and part of the team's job is to do
customer service via our social channels. We try to respond quickly whether we
have the answer or not, to let them know we're working on it. It does help the
community member feel like they're being taken care of quickly and that we're
listening to them.

~~~
jonathanjaeger
Cool, I've found the same when managing my community. There are certain bugs
or features I say might not get addressed because we're rebuilding the site
and prioritizing that over constant changes to the current site -- people are
always appreciative with good communication. If a company makes a mistake,
winning them over with customer service often creates an even stronger
user/customer.

------
carokopp
Thanks so much for the awesome replies, all! I'm looking forward to discussing
a few of them more with my team. :)

