
Ask HN: How do you handle customer support on your site? - supersan
Hi,<p>Customer support can make or break a site but for those with small businesses, handling customer support can be a real nightmare (esp. technical and billing questions). You can of course hire full time employee(s) but that is not an option until your site is making a sizable income, or you are funded.<p>So for the rest of us:<p>- what are the ways to handle customer support? 
- Do you do it yourself, outsource it to some other site &#x2F; person, or have hired person(s) do it?
- What is the average time it takes you to resolve customer queries? 
- How much budget do you allocate for handling customer support?
======
patio11
My companies have supported X00,000 users and ~8k paying customers over the
years with a maximum team size over that interval of, ohh, 1.25 or so. It's
quite achievable by a small team.

I did all my own CS, over email, for the first 6 years. This was approximately
4 years too long. Time to first response (TTFR) was generally on the order of
"I'll get back to you by the next business day on a best effort basis" \-- I
hit that on about 98% of customers for the first few years and then probably
slid later, particularly when sick or overwhelmed.

My first (B2C) product had a lot of not-very-critical CS issues which also
weren't very complicated to resolve. After having done that for 6 years, I
hired a VA firm in the Philippines who staffed me with a single person for ~4
years. I think it was 20 hours a month for $300 or so, IIRC. I acted as tier 2
support for her. She probably head off more than 90% of inquiries. We used
Snappy (BeSnappy) for CS software -- I enjoy it rather more than I do support
over email, and it was easy enough for her to get spun up on.

I've also done B2B support for my other SaaS product, which has fewer users,
fewer customers, fewer incidents, and _radically_ higher maximum-criticality-
of-a-ticket. Again, did it all by myself for the first few years. Eventually
it became obvious that a supermajority of our support was onboarding for new
customers, so when I hired a sales manager we mutually decided to roll that
into her job description. Our process is she firewalls me from any ticket she
can and, if anything survives, she dumps it into Slack as a morning roundup
every evening. I either get her instant answers or tell her "#3: ETA
tomorrow."

My sales/support person works near my customers timezone-wise, so they
generally get very quick "Thanks for the email. I'll ask my tech guy about
that and get back to you." acknowledgement for the harder issues (and very
fast resolutions to the easier ones). This makes for mostly happy customers,
although to-be-fair most of them thought I was pretty responsive back when
they wouldn't even get first contact until a day after they had sent in the
ticket. I'm not competing with having a super-responsive startup team on
speeddial; my customers expectations' are set by bureaucracies which take
weeks to acknowledge receipt of the first of three things required to get the
ball rolling on opening a ticket.

Fully-loaded cost for my sales/CS person is on the order of "a few thousand
dollars a month." for what I'd estimate as approximately 0.25 FTEs. (Worth
_every_ penny in decreased stress level for me.)

Customers occasionally ask for 24/7 phone support. I quote Enterprise rates
for anyone who wants that. No takers, thankfully.

I feel like the median experience of my customers getting CS from the team and
myself is probably worse than it was when I was doing 100% of the CS, but it
is not obvious to me that is true of their _perceived_ experience, and we've
managed to successfully manage expectations from customers about how much of
my personal time is included for $29~$199 a month. (A _particularly_ good
thing as I won't be involved in that business much longer.)

Anecdata: 80% of CS incidents take < 5 minutes to resolve, 15% take < 20
minutes, and 5% take Way Too Long.

Favorite tricks for CS:

You're going to get the same issues _a lot_. Keep a list of them. Fix the ones
that are caused by fixable product issues, and keep fixing them until those go
away.

Build self-help tools for the issues which are high-frequency low-value-added
like, most obviously, password resets. (Yes, there are still companies without
automated password resets. I know someone with a master's degree who carries a
beeper on Saturdays due to their company's refusal to spend money on tweaking
an application to allow password resets.) Routine billing inquiries, etc are
often also candidates for this.

You're now looking at a long tail of issues, but it _still_ has a fat head of
the distribution. Process-itize those issues which are amenable to it: you
want to have a Google doc which explains exactly the company standard response
to X, including what to say (templates optional) and what, if anything, needs
to be done in internal tooling. Do not extemporize a solution to the same
problem 100 times: cache it and save extemporization for places where the
team's brainsweat actually adds value over "the right answer delivered very
efficiently."

Final thoughts: your expectations for CS are not your customers' expectations.
Your expectations for your company's CS are not your customers' expectations.
Your desired outcome for a CS incident is not your customers' desired outcome.
I can keep banging this drum for a while. It's important.

~~~
dennisgorelik
What are the differences between your customer support desired outcome and
your customers' desired outcome of CS?

~~~
chc
I don't know what Patrick was thinking of specifically, but I know many people
will call customer support looking for handouts rather than support. They'll
say, "My $5000 Whatchamacallit has a blemish on its whozit. This is
unacceptable. No, you can't fix it. I want a new one free."

~~~
dennisgorelik
So, should we bend to our customers' wishes or only provide actual support?

------
jakobegger
\- Just use email.

\- As long as possible, handle all requests yourself.

\- If people keep having billing issues, use a different solution for billing.
I use Fastspring, and issues are rare. And I can just forward billing related
issues to Fastspring support.

\- If you keep having to deal with technical problems, fix your product.
Ideally it shouldn't need customer support. If it is so complicated that
customer support is required, charge at least $100 per customer.

\- Write good documentation. This is so often overlooked. People generally
contact support as a last resort, and will usually read all documentation in
advance. If your docs explain it, they won't need to contact you.

\- Time: it usually takes me 10-30min to answer one support request. I don't
have a time budget, I try to answer as quickly as possible. Being responsive
makes a great difference to your customers, and they will be much more likely
to buy your product and recommend it to others.

\- However, to limit the time per week I spend on customer support, I do
everything I can to make sure people don't need to contact me at all. I try to
fix every reported issue permanently so that I never have to deal with it
again.

~~~
danielbarla
I agree with most of what you said, and try to follow a similar approach as
well. Especially pre-empting support issues by fixing the product. That said,
I'm not convinced about documentation - a large percentage of enquiries and
support calls we get could have been resolved by checking the documentation,
or even just reading the landing page of the website. I'm still not sure how
to efficiently resolve these.

~~~
craigvn
With documentation it will only be used if it is visible. If they have to exit
your program and go to a website and search it won't be used. If you have a
prominent (not hidden in a menu) search for help option it will be used.
Assuming the search function works well.

~~~
danielbarla
The documentation is HTML, but it's linked directly in the app, so you can get
relevant information and tutorials about the function you're using.

Most of the time these inquiries are related to "can it do X", rather than
"how do I do X" \- my best guess is that they want something in writing
(therefore passing the responsibility for making the claim to us), rather than
doing their own reading and confirmation. It still takes a fair bit of effort
to answer all of these.

------
nedwin
You start by doing it yourself. This is super important. Doing support brings
you closer to your customers to understand their pain points so you can build
a better product.

Technical question that they don't get? Either make it more explicit in your
product, on your sales page or in your documentation. Once that's solved you
should better understand customer needs and have fewer support tickets coming
in.

Billing can be a little more painful but with a solid FAQ and some email
templates over time this should resolve itself pretty quickly.

Non-product related enquiries (usually like billing) are the first ones you
might outsource to someone else to handle. You can use services like
influx.com to handle this.

------
apandhi
1) Sign up for intercom.io. It's genuinely the best customer support tool I've
used.

2) Get the app and get a notification for every user's question. Try to answer
them the second you see it.

3) Don't hire a dedicated customer support person. Stay close to your
customers and build a relationship.

4) Watch this talk by Patrick Collison from Stripe:
[https://www.youtube.com/watch?v=nnllRegL_NI](https://www.youtube.com/watch?v=nnllRegL_NI)

5) Build out an FAQ

6) Make sure your customers are happy.

~~~
abrkn
I also wholeheartedly recommend intercom.io

~~~
apandhi
They are, hands down, my favorite company at the moment. Been a loyal customer
of them for about a year now. One of the few companies I will go out of my way
to recommend to people.

------
lenidot
I'm the co-founder of a company that provides "elastic customer service"
(influx.com) and I'm happy to share with you what I see happening in practice.

Most founders start out doing customer themselves. This is absolutely the
right thing to do for reasons outlined elsewhere in this thread.

When the business grows, the the founder(s) can't continue handling 100% of
customer support, both because there other priorities and because the volume
grows beyond what the founders can personally handle.

Generally in this "transition phase" time-to-first-response grows steeply.

I wrote about my experience providing customer support on a open source
project, you can see where the "wheels started to fall off" \- ie time to
first response climbed steeply:

[http://moniker.net/2013/07/10/two-open-source-emails-a-
day-f...](http://moniker.net/2013/07/10/two-open-source-emails-a-day-for-five-
and-a-half-years/index.html#time-to-first-response)

At the time, I felt bad about TTFR growing steeply. I now understand that it's
a really common state of affairs.

So at some point, the founders need help, and they either hire or outsource,
or do a combination of both.

You asked about "the average time it takes you to resolve customer queries". A
typical time-to-first response before Influx starts working with a client is
12-15 hours, with a outliers at 1-2 days.

On "stay close to your customers" \- it's 100% correct but a harder question
is "how do I stay close to my customers and scale at the same time?". The
answer depends on the size of the business. I see people using a combination
of metrics and qualitative insights. The metrics look after big picture health
and qualitative insights involve customer support staff bubbling issues back
up to the product+dev teams.

------
veesahni
Great businesses provide great customer service

Some principles worth following:

0) Be human - personable, friendly and honestly there to help

1) Be honest and transparent with technical issues

2) Be fair with billing issues

3) Be effective. Fast responses don't help if the question isn't answered

4) Empower your team to do the right thing - most big co's fail here.

5) Keep the feedback loop between yourself and your customers tight -
everybody on the team should help out on support. Lots of valuable insight can
be gained here. While outsourcing makes "support questions go away" it also
cuts off an important feedback loop.

~~~
agopaul
These are good points, but for point 3, I chose a hybrid solution. Reply
quickly that your team is looking into the issue/ticket and reply later with
the real answer.

From personal experience with other's support systems, sending support emails
and not getting an immediate feedback doesn't feel great

~~~
jakobegger
Make sure that the initial answer is from a human, though. Your customers need
to know you've received and understood their requests. An automatic reply
doesn't help much.

~~~
veesahni
Agreed. Automatic acknowledgement emails tend to result in disrupting phone
notifications with very limited useful value.

Where auto acks are are valuable, however, are for emails received outside of
business hours. This sets expectations that you may not receive a response
until the next business day.

------
hendry
Yes, have a good FAQ which becomes your canonical reference point.
[http://dabase.com/blog/How_to_create_a_FAQ_that_does_not_suc...](http://dabase.com/blog/How_to_create_a_FAQ_that_does_not_suck/)

I have a fairly complex Fastmail email setup in my organisation to share the
support mail folder with my colleagues. Ultimately all people added to support
can see all past "conversations" and join the conversation. Huge PITA to setup
though. Still prefer it as it's not locked into the semantics of some
ticketing system evolving to be email.

------
joeguilmette
Support for WP All Import is one of our biggest selling points. We get a lot
of support requests in part because our software is complex and WordPress has
a low barrier to entry.

We have three part time employees and one more in training all to handle
support. We did, however, start where you are. Here's my advice:

\- Just use email. We tried Zendesk, Groove, and Helpscout. Helpscout is far
and away the best.

\- Your reps need to be smart, talented, and close to the business. That means
you need to handle all support inquiries until you can afford to hire someone.
When you do hire someone, make sure they're 5x more technical than you think
they need to be. We hire developers as support reps.

\- It takes us on average 2 replies to close a ticket. A reply takes us on
average 6.5 minutes to write (some take 30 min, some take 30 seconds). Our
tickets involve lots of debugging and weird stuff, so YMMV.

\- Answer every support request as fast as possible. Our customer happiness
ratings have a lot to do with how quickly the reply was sent.

\- Treat support like a focus group. In a perfect world no one would ever need
to ask you for help. If you get people asking the same question over and over,
change your product to answer their question for them.

\- Docs are a last resort. It depends on the product, but often documentation
is a band aid for bad UI. That said, it's good for SEO.

\- As you grow, keep support close to your ear and heart.

~~~
supersan
> We hire developers as support reps.

Wonder why I never thought of it. Hiring a programmer to do customer support
is a really good idea since for the sites we have a dedicated customer support
guy (outsourced) they often come back to us to explain trivial questions like
"how to embed a code", "how to publish on site X", etc which can be easily
solved when someone knows a little programming. They can also offer some
creative solutions which instead of just following a script we give them.

I will def keep this in mind when we need to hire next. Thanks.

~~~
joeguilmette
It doesn't make sense for every product, but for us it's absolutely necessary.
In general I think it's really helpful to have your support reps be 5x more
technical than your average user.

------
mikhaill
When you’re a small business, it's important to establish repeatable methods
that customers and your support team can follow easily. Do not over
complicate. Find the single most efficient and scalable delivery method and
perfect it. Start with email based support. Build your reputation as a
dependable, knowledgeable and responsive machine through that single channel.
You’ll later be able to expand to the other channels but not until you can
afford it.

Depending on the size of your business I would suggest some tips from this
blog post:

[https://www.monsooncommerce.com/2015/11/customer-service-
sof...](https://www.monsooncommerce.com/2015/11/customer-service-software-
companies/)

------
jakejake
I think a chat widget on your site is a convenient way to offer support that
works for a single-person company or a dedicated support team. We use Zopim on
our site. It's the only way that I know of were one support person can offer
real-time help to multiple customers at the same time. (or at least give that
perception as long as not too many people are chatting at once).

Having a knowledge base and/or documentation is a great because a lot of
people do prefer to help themselves. That cuts down on the volume of support
calls too, so it's an easy win.

I personally think that support and sales go hand-in-hand so, especially when
you're getting started, you need your customer's support experience to be
excellent.

------
hermitcrab
To me it is key that no-one gets between me and the customer. That feedback is
essential for improving my products. So I've done all my own customer support
for the last 10 years. The challenge is how to provide great support without
being swamped.

I probably spend 30-60 minutes per day replying to support emails (I haven't
measured it). Most take less than 5 minutes.

Here is an article I wrote that summarises what I've learnt:
[http://successfulsoftware.net/2012/08/21/tips-for-great-
soft...](http://successfulsoftware.net/2012/08/21/tips-for-great-software-
technical-support/)

------
asadm
Be real. Make relationships with customers on first name basis. Specially when
the customer is from SMB or a startup.

I have my customers on my skype/email/intercom. We have looong threads with
them, discussing features and related things.

------
symkat
I run romanhaze.com - we sell eliquid for vaporizers.

Support and questions are handed through email. We have a contact form and
various internal bits will direct a customer there with preselected subjects
(e.g. "Question for Order #n" ).

I would never outsource it from the company, and want to have me and my co-
founder primarily do it. It's the closest contact you have with users who are
experiencing problems. If you're big enough, you're going to need dedicated
support people, but I think founders should still have a grasp of what
customers are asking you about.

------
mokkol
I run www.nusii.com and we are still quite small and we handle Customer
feedback ourselves. Se use it to get to know our customers. We have some saved
replies we use over and over again, and we link to tutorials where we can. I
think we take 30/45 minutes a day to do customer feedback.

I must say, great customer service helps churn a lot. Helping them out
actually makes them a happier customer and it is a great moment to start a
good relation. See it as a opportunity and don't outsource it too soon!

------
tzaman
Intercom is by far the best customer support tool I've used (and I tried 10+).

We use it both as a widget on our landing page and our support email redirects
there, which allows us assigning tickets effectively to the team member
responsible for their resolution.

Interesting fact: Because our median response time on Intercom is around 12
minutes we convert about 80% of all inquiries (from visitors to paid clients).
80%!

Bottom line: customer support makes a huge difference, so you should
definitely do it yourself.

------
michaelbuckbee
This is something I'm really passionate about. I'm a solo founder of a service
(SSL installs) that has a disproportionate amount of onboarding technical
support issues that absolutely have to be resolved or people immediately quit.

When I started, I was really concerned that support requests would be
overwhelming. It's a direct time sink (time you could be using for marketing
or development) and when you're getting off the ground it is really difficult
to predict how much time it will take. To some extent being 'swamped with
support' is a nice to have problem as it implies that you at least have
customers or at least people trialing your product.

So, it is with a fair deal of surprise that I've come to really enjoy
providing support for ExpeditedSSL, that support has become a huge driver of
word-or-mouth referrals and has driven any number of big user experience
improvements.

WHY DELIVER GREAT SUPPORT Beyond, just trying to keep your customers sort of
generically happy, there's two really important reasons to try and nail
support:

1\. Support Effort is Weighted to New/Trial Users

To get a new user of your software you have to attract visitors, teach them
what you do, maybe email them a few times and then after they signup and
you've expended all of that effort and expense it's crazy to throw away an
opportunity to keep them.

Early user support is incredibly lucrative as it's the difference between
keeping a trial customer and them leaving. A 5 minute email to a new user that
keeps them around for a year of service can easily earn you hundreds of
dollars.

2\. Good Support Is How You Get Fans

With rare exception, people seem to get more upset over support issues
(unresponsiveness) than from actual issues.

Most places are so bad at support that if you're able to respond quickly, fix
their problems and in general not act like some stiff support robot you'll
make people really happy and huge fans.

This effect is so pronounced that I almost wish we could have some minor issue
occur in the onboarding process that we could reach out to people about.

This is an area where you as a startup actually have a profound advantage over
larger companies as you're likely much more knowledgeable about your product
and definitely more invested in a user having a good experience than some
random for-hire support person at BigCo.

WHAT TO SUPPORT It's easy to lump all post sale activity for a customer into
'support', but splitting it out into a few broad categories helps address the
underlying issues in each.

Technical Support

This is what most people consider "support". A user reaches out with an error
and after some troubleshooting you tell them how to fix it.

Onboarding/Usage

Not necessarily that there is an error, but perhaps they don't know what to do
next or need assistance in getting their data loaded or preferences setup.

Customer Service

Typically billing, renewals and anything else regarding the service outside
the core functionality.

HOW TO DO SUPPORT

EMAIL

Your primary means of supporting users is likely to be email. It's
asynchronous but lets you respond quickly and starting out will likely be
sufficiently organized to keep things moving without a full blown helpdesk
application.

Secondly, it lets you be extremely precise and copy & paste friendly in a way
that phone calls can't match. Ex: we often have to help people set their DNS
entries and it's much easier to email someone the following than explain it.

Please set your www CNAME to fugu-2034.herokussl.com

Email is in fact so predominant as a support tool that you can actually go
quite far with managing support requests in your email client before you need
a dedicated support app/service. Modern email clients that nicely group emails
into threads are more than adequate to get started.

A few months after starting I switched from a dedicated Gmail account to
Fastmail and it made a profound difference as just receiving and responding to
emails was faster by about 10 minutes on each side.

SKYPE & PHONE

We primarily use Skype and Phone calls as an escalation method. If someone is
really turned around conceptually as to what needs to happen to get things
working; often a short phone call can put things straight.

I'm also always on the lookout for users phone numbers in their email
signatures. I'll sometimes just call them back if they email in with a
question or problem as this is such a huge inversion of their expectations
(being left on hold with instrumental covers of ABBA tunes playing and a
disembodied voice that talks about "call volumes" and how you're "very
important to us") - that they'll hopefully feel really positive about the
experience.

CHAT

I had really high hopes for chat, and had tried using Olark for several
months, but whatever combination of user experience and expectation that came
through, just did not get any takers.

I'd really like to offer real-time chat as a support channel and may try it
again in the coming year.

TWITTER

Some developers still look askance at Twitter "If I'm building a business, why
do I need to know what people had for lunch. Har Har." \- but it is undeniably
a support channel as people now have an expectation of being able to say: "Hey
COMPANY_NAME - I'm having trouble" and get a response.

Further, while all the other support mechanisms are at least within your
control (aka you're not going to get support phone calls if you don't have a
support number) - Twitter is most definitely not. People will tweet about your
product or service and the issues they have with it at the drop of a hat.

To help these people you need to monitor Twitter, I setup a custom column
within TweetDeck that searches for ExpeditedSSL and "Heroku SSL". Which makes
this a breeze.

WHAT TO SAY Whatever the support channel that a request comes in from, I try
to incorporate the following elements of what I've found makes a great support
experience:

1\. Apologize for them having had to waste their time: "Sorry you have to deal
with this hassle"

2\. From the context make sure that they know it's a knowledgable live human
that is invested in fixing their issue; not a NLP auto-responder script, not
an intern with a list of set support responses.

The easiest thing to do is just look at their email address or signature for
their name and put that in your salutation.

3\. Explain what they need to do in the exact way that they need to, this
means that I'm not cutting and referencing things like "set the dns cname to
example.com" \- but actually put their domains, names, servers, etc. into the
instructions.

4\. Try to explain what caused the issues. We sometimes have issues with our
upstream cert providers, sometimes weird things happen with the Heroku API,
once I forgot to buy more credits (I have to purchase certs ahead of time). I
just try to be really honest about what happened.

5\. Sympathize - we're really lucky that all of our customers are genuinely
competent developers. But they don't typically do DNS work or other config
tasks - so they feel bad about not knowing what to do.

6\. Anticipate - beyond just fixing their current issue, point them to the
next step that they need to accomplish.

MAKING A SUPPORTABLE SERVICE Some of the highest ROI time I've spent on
ExpeditedSSL was in user experience reviews. I'd ask a friend out to coffee
(or random people on Twitter to join me on Skype) and just ask them to try and
get through a SSL Install. I'd watch their progress and flich and be
incredibly embarrassed as they got stuck on seemingly "obvious" steps.

Some of the companies I've worked for have spent tens of thousands of dollars
on doing customer feedback and user review studies.

So with that in mind, it's quite reasonable to consider every support case as
a free, mini lesson on UX that a real actual user has sent you. As a direct
consequence of support cases we've:

\- Added a "Test Email" button the the approver addresses

\- Automatically force the best option for 'www' vs naked domain names

\- Improved the DNS checking to say both what should and what should NOT be
done with DNS

\- Added post install instructions for configuring the most popular app-stacks
for forced ssl.

Together this forms a feedback loop, where as you improve the product you get
fewer and fewer support issues that you can then proportionally handle better
and better. To help encourage users to give feedback I always put my title as
'Developer Support' so that they can feel more free to complain to me about
product issues than if I had my CEO or Founder hat on.

~~~
gkop
> A few months after starting I switched from a dedicated Gmail account to
> Fastmail and it made a profound difference as just receiving and responding
> to emails was faster by about 10 minutes on each side.

Would you elaborate on this point please? 10 minutes?! Each side?!

~~~
jquast
Presumably greylisting? does gmail do that?
[https://en.wikipedia.org/wiki/Greylisting](https://en.wikipedia.org/wiki/Greylisting)

~~~
atmosx
I used OpenBSD's spamd (not to be confused with spam-assasin'g binary). Spamd
greylisting is extremely effective but hard to configure properly. It assumes
that every SMTPd[1] out there respects the RFC: When a mail is rejected for
whatever reason, should be sent again using the prior IP address to get
whitelisted. Google and nearly all corps/mail providers switch IP address when
they re-send an email. It's probably a measure to circumvent IP-based blocks,
but it breaks OpenBSD spamd's implementation. If you're in a hurry or
expecting an important email, you're out of luck. It might take 12-24 hours
before the mail finally reaches your mailbox, which is simply not acceptable.

That said, the amount of spam using spamd fell to nearly 95% on the other hand
I had to whitelist manually 81 IP addresses in ~ 6 months.

------
DrScump
First of all, _billing_ questions need to be segregated to sales or accounts
receivable, as they are not technical support issues.

Secondly, how many of these queries are related to customer education /
misunderstanding of product use vs. actual software defects? The former may
reflect weak or inaccurate documentation or conflicts in design.

------
nodesocket
Intercom.io for all your support and customer tracking needs. It also handles
DRIP[1] e-mails and doubles as a sales live chat.

[1]
[https://en.wikipedia.org/wiki/Drip_marketing](https://en.wikipedia.org/wiki/Drip_marketing)

~~~
username223
Don't do this if you consider your "customers" to be human beings (vs.
resources to be exploited). Also, don't do this if you want them to keep
paying attention to your desperate and cynical begging. If you "drip" them,
most will just add you to their spam filters.

~~~
gkoberger
Just to clarify: Intercom itself is amazing and the best way on the Internet
to support your customers and treat them like humans. The problem is drip
campaigns, which is only a small portion of Intercom. (And, Intercom's are
triggered by actions, which makes them better than the average drip campaign).

(Nope, I don't work for Intercom. Just a huge fan.)

~~~
ryanlol
Intercom might be amazing, but the huge security issues it usually introduces
aren't.

I'd rather not let a bunch of random companies inject arbitrary code onto my
website.

~~~
rbinv
What about externally hosted JS libs or ad/tracking scripts? Yes, you can do
without all of them, but I don't think that's the case on most sites.

~~~
ryanlol
You can (and mostly, should) do without externally hosted JS libs.

Ad/tracking scripts is where it gets interesting though, although I'd argue
for in-house analytics ads are often a major source of income and therefore
business critical.

In the end it just comes down to trust, but keep in mind that if you trust
Intercom you're also trusting www.icb.co.uk (which just happens to have
several persistent XSS vulnerabilities in their ticketing system that could be
quite trivially be used to hijack intercom.io), AWS, gandi, google, linode
(seriously?), optimizely.

And that's just a quick 5 minute audit of the critical infrastructure
providers for intercom.io, I strongly believe that if any of these were
compromised the attacker could trivially take over any site that is including
intercom code on their page. And don't forget, this could also be done
recursively, for example optimizely uses edgecast. An attacker that
compromises edgecast would be able to insert code into intercom.io.

Google fares much better against such inspection, as it relies much less on
external infrastructure providers.

And since there's no real reason for intercom.io to require users to remotely
include their code, I'd avoid using them until they fix their product.

~~~
rbinv
Thanks for elaborating.

What do you mean by them "fixing their product"? Make it self-hosted/server-
side?

~~~
ryanlol
Only the javascript code (and any html) would need to be self hosted. It could
still communicate with intercoms API servers, just not load code from remote
locations at runtime.

------
caruizdiaz
We keep it simple, accepting only email and phone support.

\- For emails we use Zendesk (zendesk.com) \- For phone support we use Toky
(toky.co)

(I'm the founder of Toky, and we dogfood our solution :))

------
tmaly
I use email, but I also make a FAQ entry to address every question I get. I
got the idea from the 4 hour work week.

------
dools
HelpScout + outsourced tier one support

~~~
astrowilliam
NEVER outsource support. Never-ever lose focus on your customers needs by
adding another layer of people and software.

~~~
dools
There's lots of support functions you can outsource. You just have a
preconceived notion of what "outsourced support" means.

------
maximgsaini
Disclaimer: We run a Heldesk software, Busibud.com which maps out a company's
customer support process and helps them outsource only the mapped out part.
The helpdesk software is free to use.

I've been helping companies setup their customer support processes for some
time now. Initially, founders/core team members must do customer support on
their own. This should happen till your team has some visibility of the
process (what kind of questions you get and how to reply to them).

\------- What are the ways to handle customer support?

You can do it synchronously (chat or phone call) or asynchronously (email).
Usually, async customer support requires lesser money/time because things can
be structured. But, before you have some visibility of the process and are
still finding p/m fit, I would suggest you talk to people.

\------ Outsource vs do it yourself?

Before you know your process, do it yourself. No one can decide how things can
be answered. Once the process has been mapped out, a lot of the startups I
know of ask every team member to pitch in for customer support. This may lead
to better quality but leads to huge costs as well. I've seen salesmen spending
1-2 hours everyday on customer support answering what they call "dumb
questions". You can outsource it as well, which comes with problems of its
own. For starters, it will be very hard to find an outsourcing partner who
will be ready to deal with extremely small volumes.

Even if you do manage to outsource, your process will now be managed by
someone else. Ad-Hoc changes become difficult to communicate and the people
giving out support for you will also be giving out support for other
companies....hence leading to quality issues. Unfortunately, most outsourcing
companies still rely primarily on training to ensure quality. They don't use
the technology they should be using. Thus, quality will depend on the
infrastructure of the outsourcing partner (training managers, quality
managers, etc).

Once you reach a decent size, hiring people and creating your own customer
support team is an option but is usually more expensive
(HR/payroll/training/infrastructure). But, it also leads to better quality. Do
remember that customer support teams have a huge turnover rate...people keep
going and coming in. Thus, training and quality monitoring costs can be huge!!

\------ What is the average time to resolve queries?

I've seen a first response time of 5 minutes and also first response times of
a few days. Don't know what the average is but depends on a lot of factors.
The one doing it in 5 minutes usually has happier customers.

\------ How much budget do you allocate for CS?

This is a tricky question. Even huge companies have a problem with this. The
amount of budget to be allocated would depend on a lot of factors. What I
would suggest is that your get started with a particular level of resolution
time (which would determine your budget) and then try to optimize it using a
series of A/B tests with retention/return being the metric being monitored
(the metric too can depend on a lot of factors). Once you use these metrics,
you would have a better idea of how much budget you should allocate. I might
be wrong, but Busibud.com is perhaps the only customer support tool that I
know of that lets you A/B test customer support strategies.

~~~
maximgsaini
When it comes to tools and customer support problems of a growing company,
here is a post I found to be accurate for a lot of the cases I've seen:
[http://blog.outreach.io/why-we-switched-from-intercom-to-
zen...](http://blog.outreach.io/why-we-switched-from-intercom-to-zendesk-and-
almost-chose-desk-com/)

------
mmaunder
I run [http://www.wordfence.com](http://www.wordfence.com) \- We provide
customer support via Freshdesk for our paid customers (a ticketing system) and
on the wordpress.org forums for our free customers that use our open source
product.

I initially did CS myself along with my co-founder and it is tough work. The
hardest is the context switching overhead. One minute you're coding or
marketing, and then you have to switch into doing 2 or 3 hours of customer
support. What is really tough is at the end of the 3 hour stretch, a customer
with a real gnarly issue comes along and you have to do 30 to 45 minutes of
actual work researching it to help them. You have to dig deep to go that extra
distance.

Once our revenue scaled we could hire our first full time customer support
engineer and wow. It was so awesome to have someone offload this and let us
focus on all the other stuff (which we would eventually have to hire for
too!). We have a team now, some permanent and some contractors.

So there's no easy way to do it and because it's a human intelligence task,
it's super time consuming and super expensive. But I can't overstate the
importance of great customer service. We are known for it in our space and it
has really paid off. Competitors have dropped the ball in a big way and we
have picked up the slack through excellence in customer service.

A few things I learned:

\- Reply early, reply often. It's very important to most customers to simply
be acknowledged.

\- Everyone has a bad day and 90% of the time, a polite response to a very
angry customer will get you a surprisingly polite and grateful response back.

\- Twitter is great. Reply to customers, interact, but direct them to
ticketing or forums for full customer support service.

\- Ticking system is essential. It's the only way to reliably track issues.
Support via email and you will eventually drop the ball and it will bite you.

\- A FAQ will save you a huge number of support tickets. Put it front and
center, maintain it well, make it as user friendly and easily navigable as
possible.

\- Only hire people who speak your customer's language as their first
language. Even the smallest grammatical errors are giveaways of offshoring and
will irritate customers.

\- Depends on what kind of biz you run, but in our case our customers are
surprisingly understanding when we have an autoresponder saying we will be
providing limited support over the holiday season or over weekends. So pick
your hours, and just communicate clearly what they are.

Hope that helps.

Edit: You asked about average time to handle customer queries. A ticketing
system gives you that kind of reporting along with a ton of other metrics. I
would think the average time to close a ticket varies depending on the
business and product complexity and customer sophistication.

------
mei0Iesh
I unlist my contact details, and only people who can do a WHOIS contact me.
Then I talk to those like a regular person. If the system is designed
optimally, it should be inherently supportive and most people won't need help.
But it totally depends on your specific business and goals, which you didn't
explain.

