It's been a little over a year since I blogged about why company founders should do customer support for as long as possible. Here we are, one year later and our customer count has almost tripled! I think we must be doing something right, because honestly, not a lot has changed.
We support $2,300,000 annual recurring revenue with just one full time support rep. That's 10,000 individual users on 1,650 paying accounts!
So that I don't confuse you later, we actually do all-hands support and have one team member working on it full time each week.
Think one person can't pull off that level of customer support? You might be surprised. We've experienced a lot of success, and it's largely thanks to a few simple strategies.
Keeping Support Requests Low
It Starts With Usability Testing
I've said it before and I'll say it again: if you've never done it, usability testing might be the single highest-value activity you can do. You'll learn more about your product in a few sessions than you ever thought possible.
Watch people who are unfamiliar with your product go through the setup process. Keep a bottle of whiskey nearby because you'll need something to take the edge off when you realize how many could-have-been customers have slipped through your fingers due to glaring usability mistakes.
I've been building products for six years and every single time I've been astounded by how much I've been able to improve the user experience after just a testing few sessions.
Another opportunity for usability testing is to show existing users beta versions of new features. We used VerifyApp to do some usability testing when we launched Better Error Pages and it was a great experience. We're planning on using this for every major feature release in the future.
This is the single best way to grok how easy your product is to use, how gentle the learning curve is, and how convenient your users find the experience.
Design For The Novice, Configure For The Pro
I don't think anyone would disagree with Mark Suster's blog post on this subject. Everyone starts a new product with the intention of creating something that does one thing really well (without all that bloat).
"The other tools are too cluttered and hard to use, ours is going to be different." That's what we all say.
Fast-forward to a few years later and every founder can point to a few places where feature creep has taken root. Places they know that their app isn't the most user-friendly. Places that new users have trouble with. We saw ourselves going down this same path that we swore we wouldn't go down and decided to head off the problem before it got out of hand.
About a year ago we stripped literally every non-essential feature out of the interface by default and put it in an "Add-on Store".
Every new signup gets a simple, slimmed down first experience that emphasizes only the core features of the product. Once users see the primary value proposition of the product, we slowly introduce them to all the advanced bell-and-whistle features that can be turned on in the Add-on Store.
Remember that the goal is still to have people enjoy using your product; customers shouldn't feel the need to consult a manual just to get started. Besides, better usability has its own rewards, such as a higher net promoter score.
Help Your Users Help Themselves
A detailed, accessible knowledge base is an incredible asset in keeping support tickets down. Your product being user-friendly usually won't suffice on its own. The reality is that some features (integrating with an API, clarifications around definitions, etc.) require some explanation. There are plenty of tools (we use Groove) out there that make it dead simple to create a knowledge base, so you really don't have an excuse to not have one.
A lot of people miss this next step, so pay attention: it's not enough to just have a detailed, up-to-date knowledge base...you have to surface those articles in the places where your users are most likely to need them.
As an example of this, you'll notice that StatusPage.io features a little "?" button on the bottom right-hand corner of most of our pages that links to the appropriate knowledge base articles, pre-emptively answering most of our customers' burning questions.
Another mistake I see too often is people letting their knowledge base content go stale. You need to update the screenshots in your knowledge base when you make design changes.
If you have knowledge base articles around integrations you have with other companies, those will occasionally need to get updated too. Make a habit out of running through each one of your integrations once or twice per month to make sure that those screenshots are up-to-date. This is a good job for an intern if you have any.
Effect On Tickets Per Customer
Take a look at this graph. Between July 2014 and August 2015, our customer count increased from 680 to 1640 (a 140% increase).
Contrast this the number of support requests we've responded to (inbound tickets is a bad indicator because sometimes we get spammed like crazy). Over the same period, our monthly support requests has only increased by 15%.
Our continued focus on usability, a simple interface, and a strong knowledge base has allowed us to grow significantly in customer count while keeping support volume reasonable.
The Builders Should Support The Customers
I want to start off by acknowledging that all-hands support isn't for everyone. If you've tried it and determined that it's not the best thing for your organization, by all means, do what works for you.
We're huge believers in all-hands support. After usability testing, this is the number one thing I advise other companies to try if they haven't already.
If you don't know what all hands support is, read this article for a quick primer (written 5 years ago! man the internet growing up fast).
Our specific implementation of all-hands support goes something like this: everyone on the team does support for a one week period on a round robin basis. Some companies implement a "one day per week" schedule, but we've found that doing it for a week straight tends to come with less problems. We call this "being on sweeper".
(Is this where I #CEOonSupport?)
Faster Feedback Loop
Having the builders do customer support over the past few years has helped us cut down on total support tickets. Here's why:
When a support rep hears about a minor bug for the third time, the bug gets turned into a ticket. That ticket then gets tossed down into an endless pit of despair (known as The Backlog) which is where that ticket will die. It will languish for months waiting to get “prioritized”.
When an engineer hears about a bug for the third time, she promptly stops what she’s doing to fix that bug. It’s just the nature of engineers. It’s in their DNA.
Worth The Distraction
The sweeper spends about half of their time answering customer support tickets and helping people over live chat. Any free time is spent working on whatever that person's normal job entails. Yes, being on sweeper is extremely distracting. But we've that the many benefits that come from us all doing sweeper outweigh the costs.
For one, when engineers and founders do support, it's on opportunity to provide truly remarkable support. For example, when a customer inquires about writing some Custom HTML for their status page, a new employee on sweeper duty will often point them towards the relevant knowledge base article.
However, when a co-founder gets the same question, the answer is usually a lot more detailed. We point them to several companies who have really great custom designs and will occasionally even offer to do a first cut for them. This is the level of support required to create brand evangelists.
Another benefit is that when engineers have direct contact with customers, design quality increases significantly.
Tool Up
Aside from using Groove for our knowledge, we use a few tools that help us to be as efficient as possible when doing support.
A Shared Inbox Tool
We use Front as our shared inbox tool. This helps us to funnel almost all of our customer communications into one app which is extremely helpful. The “mention” feature is one of our most-used features in Front, as it lets the sweeper pull the correct team members into a ticket when they need help.
It also comes with a bunch of bells and whistles like reminders, tags, canned responses...pretty much everything you need to run an efficient shared inbox operation. Oh yeah, and they have an iPhone App if you want to answer some questions on the go.
An Internal Wiki
About a year ago, as the product started to grow and a few new team members came onboard, we started to notice that the person on sweeper duty was reaching out over Slack to find the answer to common problems. As a co-founder, it's easy to forget that not everyone on the team intimately knows the details of the entire product. We had the answers to all of the obscure questions in the back of our minds, but we weren't making that information readily available to new team members.
To fix this problem, we created a robust internal wiki that answers pretty much everything about the product that can't be found in the public knowledge base. This includes things like how to use our admin-only tools to help users troubleshoot problems, information about our own hosting infrastructure, and a fair amount of hacks to help people with some edge cases.
To date, our team has created 104 articles in our own internal Readme.io wiki. As a result, even people who are new to the company rarely need to interrupt other team members to help answer a support question...the answer is usually available in the wiki.
Live Chat
This probably doesn't result in faster support, but I wanted to include it anyways because it's been a huge benefit for us. It takes just as long to answer someones question over live chat as it does via email. Actually, it probably takes a bit longer because of all the formalities that occur during live chat.
We've used Olark for this since we launched the company and would definitely recommend it to anyone looking for a solution.
But there's something magical about having your question answered in person. A lot of my most memorable interactions with customers revolve around me fixing a problem for them in real-time and them being over the moon about it.
Final Thoughts
The reality is that being able to support this many customers with just a single full-time support rep is the result of many small decisions. It's the cumulative affect of tweaking copy, highlighting a subtle requirement, and trimming the interface down to the essential parts.
Another thing to remember is that the actual bottom line benefits to your business won't just be reduced cost due to fewer support reps. An easier to understand, more usable product results in a better user experience -- which in turn results in more of your customers promoting your company to their friends.
It won't happen for you overnight, but these kinds of results can be achieved in time. Remember: the best time to plant a tree was 20 years ago, the second best time is now.