One of the challenges of taking over a service as large as Glassboard is handling the support load that comes with it.

Since 2010, I have had Aptfolk on the payroll to handle the majority of Second Gear’s support load. I’ve long believed that my time is best spent invested in improving the products versus answering the same emails over and over again. If there’s an issue that requires my attention as the developer, Jason or Ash would escalate the ticket to me, but the vast majority could be handled as “tier 1” support. Since every Second Gear customer was a paying customer it was an expense that made sense.

With Glassboard, that dynamic has shifted as the vast majority of our users are free, non-paying customers. The ultimate goal is to convert a good chunk of these users into paying customers (while also bringing in new customers at the same time hopefully), but there’s a lot of work to do before we get to that point. As it stands today, I am paying the Aptfolks to help users who are not currently paying for the product and (being realistic) may never be paying customers. When you are a company backed by a big wad of venture capital cash this isn’t that big of an issue and can be chalked up as a cost of successful user acquisition. When you’re a small company like Second Gear that is 100% funded by our customers (and my personal bank account sometimes!) this can be a costly problem.

Free support isn’t something new. When you offer a free trial, you want to offer support and answer any questions potential customers have while they are evaluating the product. With the freemium model where there is always a level of users who will never pay for the service. Answering the question about how to handle support for these users in a way that doesn’t break the bank is something that has been on my mind lately.

As one of the ways of cutting down on the support cost and load, we recently switched to Zendesk for managing support. Yes, we switched to a paid service. Previously everything was handled by a mix of FogBugz tickets and TextExpander snippets. It worked well for several years, but dealing with a service that spreads across multiple platforms (iOS, Android, and the web) was making it difficult to track cases, analyze support trends, and burn through tickets quickly. FogBugz is great, but as a primary support tool we were hitting the pain points more than ever. Moreover, the macro support in Zendesk sold me on paying $50 a month as it allows us to quickly automate frequent questions and inquiries. If the service allows either me or the Aptfolks to iterate through our inbound support tickets quicker and saves us a few hours a month, the monthly Zendesk fee is worth it.

Free Support Is No Support?

When you’re dealing with a customer base that isn’t paying for the product, the goal is to offer as much self-service support as possible. You want customers to be able to find the answers to their questions either via a knowledge base, blog posts, or user-to-user support. As a last resort they should email you for an answer.

I’ve seen quite a few SaaS companies only offering direct support via email or phone for certain tiers of customers. For free customers, the only support options is the automated knowledge base or user-to-user support.

This is tempting, but I also can’t help but wonder how many potential customers aren’t converted to paying because they couldn’t have one of their questions answered. Obviously, I need some sort of data to measure this, but my current hypothesis is that it could be an issue.

To achieve the “No Support” option also requires a substantial amount of self-service support. This is admittedly an area that needs a lot of improvement for us, and another reason for the Zendesk switch. While we have the Glassboard Help board (Invite Code: HELP) that lets users help each other, the vast majority of support still comes through our Zendesk email address.

On the todo list is to begin working on a knowledge base that answers frequently asked questions. We’re also working with some lovely people to help with general product education that will highlight how to get the most out of Glassboard. The hope with the product education is to help alleviate the “why should I use this?” questions better.

Automating Support

There are some support tasks that aren’t as easy as pressing a button. Glassboard currently has no ability to automatically delete your account or change your email address. Why? I’m not entirely sure what the thought process was behind that when it was built by the Sepia Labs folks. What I do know is that these are the two biggest support requests we receive and that each time we have to handle one of these tasks for a customer, we lose money.

When the request comes in, we have to:

Go into Glassboard and find the user’s account

Update their email address (or delete the account)

Go back to Zendesk and email them about the change.

Possibly handle any responses that come in.

It’s not a difficult task, but it is tedious and something that we shouldn’t have to deal with manually.

Any support inquiry that comes in more than once, be it a bug users are hitting or a question, is an opportunity to automate and solve a problem with technology. In the case of changing an account’s email address or deleting the account entirely, the solution is to write code so that users can handle these tasks themselves either via the web or mobile apps.

Given that these are two areas that we are getting multiple requests for daily, it is high on my development timeline because it’s not only a better customer experience, but it’s also an opportunity for us to cut down on support costs by letting users handle these tasks themselves.

Support Driven Development

Support has long been one of the key metrics I have used when prioritizing bugs. The more a bug is reported, the more likely it is to move to the top of my development timeline because I want to make it so that we no longer have to answer emails related to the problem.

Support questions have also been a good eye opener for figuring out the most confusing areas of Glassboard as a product. Our first line of defense for these sorts of issues is to improve product education so we can refer customers to a web page or video that explains some function of the product.

In some cases, education may not be the proper solution, and is just putting a band-aid on an implementation issue. In those cases, it is worth investing the time in analyzing the user experience and seeing if there are ways to improve that. Glassboard has quite a few of these pain points that we are looking to resolve in the coming months. The biggest issue on our list is the onboarding experience of Glassboard, which I hope to share more about in a future post.

If you’re answering the same support questions over and over, take a few hours to highlight the issues that are repeatedly being hit upon. Once you have those, work on a plan to alleviate them and in turn, lower your support costs.