

Customer Support Doesn't Have to Suck - probablycorey
http://zachholman.com/posts/customer-support-doesnt-have-to-suck/

======
mvanveen
Having done support for my own startup, and now that I'm working at a startup
where support is make for break for us, I totally agree with the pov of this
post. But, ironically, I don't see any clear indication that GitHub sticks to
this culture.

Every ticket or question I've sent in to GitHub support has been met with
hostility. I submitted my third such ticket just this last week, a follow-up
to an issue I had a day or two ago, and got a rather gruff response from
Tekkub about how he had "already addressed this in the last ticket." His
response might've made more sense if I had received the response prior to
sending out the 2nd response, but my intent was simply to update with more
info.

In general, I'm a fanatic zealot about GitHub. I think you guys have put
together one hell of a product. It's like developer crack. Seriously, you guys
even got Torvalds hooked now it seems. However, I've never gotten anything but
attitude from the GitHub support line.

~~~
tekkub
I'm sorry you feel my replies were hostile, but I don't really understand why.
Here's the timeline of your two emails:

September 02, 2011 @ 09:49 PM you opened the initial bug report

September 03, 2011 @ 08:06 PM you opened the second

September 03, 2011 @ 08:45 PM I responded to the first (we work from the
oldest to newest). This was my reply:

> Thanks for the report. This is a known issue, we have a ticket open to get
> it fixed.

I continued to work through our inbox, 20 minutes later at September 03, 2011
@ 09:04 PM I hit your second ticket. That was for the same issue, with a
little extra info. I replied with:

> As I noted in the other thread, this is a known issue, we have a ticket
> open.

I honestly don't see how these replies were hostile in any way. I thanked you
for the report, I told you we had a ticket open to fix it, and then I
acknowledged the second one so you'd know that we received it.

I'm open to any suggestions on how you'd have handled this differently.

~~~
mvanveen
Hey tekkub,

Intonation and meaning is lost over the Internet, which is often frustrating.
I think this is exactly that kind of incident.

From my pov, when I come to a person about an issue and they respond with "as
I noted in the other thread..." it can come across as somewhat gruff and
dismissive. I totally get quickly clearing out a ticket and dealing with it
simply, but the brevity and tone of the response made me unsure about how I
flagged the issue. I immediately wonder if I've frustrated the support guy by
giving him further information about the issue. It's certainly an
inconvenience to get a dup, perhaps the support guy doesn't welcome updates on
tickets? I'm left to wonder whether I've overstepped by supplying more info,
and worse, I have to question if GitHub support cares about my response or if
it's just been put in the bug bin of despair.

So, all things considered, you guys are doing fine, but maybe are thinking
like devs rather than support people. Perhaps that is appropriate for GitHub:
devs are your target market. Actually, my biggest beef with your support so
far is I never was able to clear out a question about image linking in
markdown files in a GitHub repo. Right now everyone in my startup has to add
raw blob link to every single link, and this just seems like the wrong
pattern. Why should I have to prepend
[https://github.com/.../../blob/master/.../images/IMAGE.jpg?r...](https://github.com/.../../blob/master/.../images/IMAGE.jpg?raw=true)
for every image I want to link in our flat file wiki? The last communication I
had on the issue was never answered, so as far as I can tell, this is the only
way to get images to show up in markdown files...

~~~
tekkub
Thanks for the feedback. We try to at least get a reply to everyone, could you
forward me the email so I can see if I can find it? tekkub@github.com

------
422long
Working at a high-touch hosting services vendor I understand all customer
requests to be something that must be individually considered and addressed -
but that's within the context of a much larger hosting partnership that funds
such consideration on a regular basis.

Is there risk to the "positive" reputation you may get from doing this on in a
B2C or low-touch B2B environment? Will this re-anchor customer expectations
and lead to disappointment when receiving standard support?

I'm trying to think of a B2C company that's known for freebie's and a
"customer is always right" attitude (names are escaping me at the moment). I'd
feel slighted if I didn't receive that exceptionally high service level
associated with the brand.

------
toast76
I think exceptional customer support is one of the most critical and yet most
overlooked aspects of running a startup. It's how you turn customers into
fans, and fans is often the difference between winning and losing.

Through our previous app (<http://fivesecondtest.com>) and our current
(<http://bugherd.com>) I've always tried to go above and beyond. Every time we
have an unhappy customer I go so far above and beyond to help them that I more
often than not turn a hater into a fan. Turning a negative support request
into a positive Tweet shout out is a major win for me.

I can't count the number of times we've resolved a customer complaint and had
them the very next day start paying us money. Yesterday we found a customer
complaint in the "spam" folder from 3 weeks ago, we responded, apologised and
let the customer know that we're changing to Zendesk as a result. Today they
signed up to our top tier plan. THAT is a customer support win.

Today someone responded to our "how are you finding Bugherd?" email saying
they hadn't had time to try out the app, so we extended their trial without
them even asking. We do this all the time. It costs us nothing, and may win a
paying customer.

We'll offer refunds to users who we can't help, we'll give discounts when our
plans don't suit, we'll give away free months when a customer is waiting for a
feature we haven't built yet. Anything to ensure that customer becomes a fan.
Even if it turns out they leave us, we want to ensure they leave happily.

------
alabut
Holy shit, he read my mind. We're just wrapping up our yc application for
<http://inboxissues.com> \- a browser extension that is a bridge between
customer support emails and the github issue tracker. We've been calling it
rapportive for support, but it also goes the other direction: commit a fix to
a feature or bug? notify customers when the feature ships.

Apologies for the landing page, we just finalized the idea on Saturday and
we're feverishly working on updating the site with more info!

------
aashay
Anecdotal: I remember seeing this from KLM a little while ago. They take
customer service (not necessarily even support) to an extreme by committing
random acts of kindness for passengers waiting in terminals:
<http://surprise.klm.com/>

------
gnubardt
You don't need to operate in the first tier of customer support to help them
either. We have a forum that developers monitor & post to
(<http://forum.brightcove.com/brgh/?category.id=developers>). It's easy and
not disruptive to interact with customers this way and it has the advantage of
serving as a record so future users with the same problem. Users help users
too, it's not only developers posting.

------
alexkearns
I do all the support for Tiki-Toki (<http://www.tiki-toki.com>) at present
and, to my surprise (I am quite a grumpy person), I quite enjoy it.

It really helps you get to know your own software and pinpoint areas where
people are struggling and usability improvements are needed. Plus, you learn
what new features people want.

