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.