Ask HN: How do you handle customer support on your site? | Hacker News Reader

Ask HN: How do you handle customer support on your site?

77 pointssupersan56 comments

Hi,

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.

So for the rest of us:

- what are the ways to handle customer support? - Do you do it yourself, outsource it to some other site / 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?

View on HN

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.

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

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

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

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

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.

Hi Genericuser,

Our documentation located at <direct url> should be able to assist you with <problem xyz>, please do let me know if there's anything there that needs clarifying!

Kind regards,

Better:

Hi <indication that we're tracking this problem>,

... please do let <contact to avoid fighting back through automated menus and outsourced support> know...

Kind regards, <person ultimately responsible for failure>

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.

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.

That's really useful advice. Thanks.

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

I think this somewhat depends on the industry or more like your target audience. Our latest site has been quite popular with older (60+) non tech savvy people but a side-effect of that is that we get an insane amount of questions.

I've gotten questions about how to do something when the step was as simple as pasting a URL and pressing the Next button. On top of that there is a pdf download and a big help button to a YouTube video on that same page. Our support desk shows answers like Stackoverflow when somebody tries to submit that question but they still ask anyway. It's so boring replying to the same thing over and over (thank god for canned replies).

Handling customer support yourself does give you a lot of feedback about your site though. If you really love your product it can be a real eye-opener.

> ... as simple as pasting a URL ...

You need to do user testing when you watch your users use your product. Do it with your target audience. You will be floored by their lack of technicality.

Then go fix your product so they never have to paste anything.

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.

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

5) Build out an FAQ

6) Make sure your customers are happy.

I also wholeheartedly recommend intercom.io

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.

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

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.

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.

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

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.

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.

I agree with you. We actually are quite proactive and usually if there is an application error/exception, we get notified via email by the application itself and immediately write to the customer that we know about the problem and we're already working to fix it.

Yes, have a good FAQ which becomes your canonical reference point. http://dabase.com/blog/How_to_create_a_FAQ_that_does_not_suc...

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.

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.

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

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.

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

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.

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

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.

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.

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!

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.

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

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.

> 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?!

Presumably greylisting? does gmail do that? https://en.wikipedia.org/wiki/Greylisting

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.

Yeah, this is obviously anecdotal and maybe I was some special case as much of the support was to "new" domains that people were setting up (which is why they needed SSL, etc.) but switching to Fastmail was a huge win as we were close to IM levels of back and forth and there were many occasions where if we intervene early before a customer makes a change it can really help them.

I suspect that it's due to Gmail being free that they have an immense amount of anti-spam rules, timeouts and checks to try and keep things reasonable. Since everybody is paying real money to be on Fastmail much of that likely isn't necessary.

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.

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

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.

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

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.

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.

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.

Thanks for elaborating.

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

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.

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 :))

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.

HelpScout + outsourced tier one support

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

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

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.

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

I run 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.

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.

Reply on news.ycombinator.com