One of the things I have been thinking about a lot recently is the architecture of Glassboard. Now that I have everything mapped out for where I want to take Glassboard’s direction going forward both financially and functionally, it’s the time to look at how to actually build that functionality into the existing code base.
The Current Glassboard Architecture
Glassboard’s backend is powered by Microsoft Azure. In terms of computing, there are three main components: two worker roles and one web role.
Azure defines a Web Role as a server that has a running copy of the IIS web server on it, so that users can connect to it. A worker role doesn’t run IIS, but is still a Windows Server instance that you can use to do things like background processing on it and offload some of the heavy activities from your main server role.
This is a rudimentary diagram of the Glassboard architecture as of April 2014.
The Kitchen Sink Web Role: I currently deploy a single web role that autoscales between 2 and 4 instances based on user traffic. This single web role does a lot. It handles all user authentication and signups as well as managing and distributing the Glassboard JSON API (through WCF god help me). In addition, it also has a few web hooks connected to it, and the Glassboard web app which is a rudimentary ASP.net MVC application with a Backbone.js exterior. It’s a beast.
Attachment Processor Role: When you upload a photo or video to Glassboard, it’s thrown into this role to do some post-processing like rotating it to the proper orientation and compressing to save us some server side bandwidth. Right now it’s using ffmpeg, Handbrake and a bunch of scripts to accomplish this. It’s more brittle than Greg Oden’s knees. We’ll get to refactoring it eventually.
Notifications Role: The Notifications Role handles distributing all the push notifications and emails that are sent out through Glassboard. Currently it supports Apple’s Push Notification Service, Google Cloud Messaging, Google’s legacy Cloud to Device Messaging, and Microsoft’s legacy Windows Phone Notification Service. Email is distributed via Sendgrid.
Everything in the current Glassboard architecture is housed in a single Visual Studio solution with about 36 C# projects in it. It’s a lot of code to manage. Luckily it’s also well tested, which makes it easier to manage.
Current Notification Role Issues
There are a few technical and ideological issues I have with the current notification architecture.
To send messages between the web role and the attachment processor and notifications roles, I use Azure’s Storage Queue mechanism to pass messages. When you post a message to one of your boards, the web role generates a new XML payload in one of our storage queues that the Notification Role listens for to handle the processing.
Sometimes this queue and the processing gets extremely backed up. Usually the CPU usage spikes to around 90% or higher for long periods of times which can lead to message postings being delayed for several minutes (in some cases I’ve seen hours) at a time. This is no good, especially when building a messaging service.
I’m not sure what the cause is for the spiking CPU other than a lot of delicate C# threading issues which I’m guessing are running amok.
The other issue I have with the notification role is how much of the code for things push notification services is in-house built. At the time Glassboard was originally built a few years ago, there weren’t too many open source solutions for handling push in C# I’d imagine.
I’m fairly conservative when it comes to third-party dependencies, but for things like push notification services there’s not much sense in maintaining your own code library to connect to the service when there are a few good solutions out there used by hundreds (thousands?) of startups and businesses around the world. They’re well implemented, battle tested, and code that is maintained by the community.
Being on C#, that limits the amount of options I have for dealing with push providers. PushSharp seems to be the main provider out there.
The New Notifications Role
Given that I’m not a fan of the C# threading model currently implemented, the amount of code used to power something that’s relatively simple, and the homegrown nature of many of the push wrappers we’re using, I made the decision to rewrite this portion of Glassboard’s architecture using Node. Hang on. Put those Buzzword Bingo cards away. I’m not a fan of rewriting for the sake of rewriting either.
Ultimately, my decision to switch to Node is all about code management. I’m confident I can accomplish the goals of my notification roles with a lot less code using Node than C# thanks to it being a bit less verbose of a language and a variety of NPM packages I can take advantage of for handling APNS, SendGrid, and GCM. The less code I have to manage and maintain, the easier my job is as the sole developer of Glassboard.
I don’t believe I will have any performance degradation in switching from C# to Node for this portion of the code either, though it’s hard to tell before actually writing the code. If anything, I’m optimistic that performance will improve.
A Fork In The Road
There’s two different ways I can approach handling push notifications being distributed through my new worker role. The first is to use these npm packages like node-gcm and its similar ilk to distribute the messages myself like I have always done. The difference being mostly in the language being used (Javascript versus C#).
The other option is to take advantage of Azure’s Notification Hubs which will handle distributing the messages to devices for me. Notification Hub has some advantages that stand out to me:
It works with all the platforms I care about: APNS, GCM, and WNS.
It handles platforms I don’t care about, but might again someday: Kindle.
It does all the device feedback management for me so I don’t have to keep track of which devices I should be adding or removing (such as when a user installs or uninstalls Glassboard).
Tagging devices based on certain features seems appealing. For instance, I could tag all of a user’s devices by their UUID and then easily distribute a message to all their devices in one message.
This all sounds great. Why not just do this? Cost.
Notification Hubs are another cost layer on top of the existing charges I’m paying Microsoft for my cloud instances and storage. I’m still in ‘losing money’ mode with Glassboard, so I’m trying to be fairly conservative with my spending.
Glassboard currently sends around 150,000 emails a day according to Sendgrid, but I have no idea how many push messages it sends because it has never had a way to track that sort of information. If I opt into Notifications Hub, I’m likely going to be out at least $200 extra a month, but that could also sky rocket to an even higher amount.
Now you understand why I am giving so much important to data and analytics these days.
My gut says use Notification Hubs. My wallet says roll my own.
Service Bus vs Storage Queues
One last thing I’m still debating is whether to keep using Azure’s Storage Queues for managing the messaging between the different components in my cloud stack or to use the new-to-me Service Bus functionality, which looks to offer a few more features. The Notification Hub functionality Microsoft offers is powered by the Service Bus, which has me considering the switch.
There are plenty of decent articles out there comparing Service Bus vs Storage Queues, but from a more abstracted level that leaves me still questioning which way to go. The conservative developer in me says keep using what I’ve already got because no major Service Bus feature stands out to me as a must-have right now. The liberal developer in me sees Service Bus as the more modern architecture that will likely be able to grow with me as Glassboard (hopefully) expands in years to come.
Feedback certainly welcomed.
Writing The Code
Even though the core architecture of two worker roles and a single web role won’t change with this refactoring of Glassboard’s notification architecture, hopefully this has been at least a little eye opening in terms of how Glassboard is built, and how I envision it being built going forward.
The obvious next step is to write the code, which I started earlier this week by writing the unit and integration tests for the new Node code base.
Since I spend so much time in Visual Studio these days, I thought I’d give the Node tools that Microsoft released a try. Then I remembered that while I love what Microsoft is doing with the cloud and Azure, Windows is still Windows.
Data analytics gets unnecessary grief. When most people think of analytics, they envision Google or Facebook following your every move on the web to figure out what sort of ads to show you while you are browsing. This is pretty creepy.
Admittedly, it’s pretty easy to shift over to the creepy side of analyzing user data, but that doesn’t mean that all data analysis is bad. In fact, it is essential if you want to run a successful product.
When I took over Glassboard, there wasn’t that much data on how the service was being used. None of the apps used analytics, and the server side generated a basic report that contained some basic vanity analytics such as user signups, boards created, statuses posted, and the like.
This is interesting information to notice from high-level analytics like user signups growing or dropping off, but it doesn’t tell us who is using the service or how they are using it.
Why Analytics Matters
Who, how and why are the most important questions you want to answer when you are starting to work with data analytics in your mobile products.
Who answers what the current audience for your product is. Your audience dictates how you should charge, what features you should add, and what marketing opportunities you may have as well. If you don’t understand who your audience is, pricing and targeting becomes really difficult.
How answers what ways users are using the product. Are you primarily getting users on Android? iOS? What’s the breakdown of iPhone vs iPad? How’s the web app doing? You want to put most of your attention on the platforms people are using, so knowing how people are using is important.
Why answers the reasons that someone is actually using your service. This one is a bit more difficult to gather without crossing the creepy line, and I’d argue its less important than the first two. There’s ways to gather this information without crossing the creepy line, which I’ll cover later on.
Choosing an Analytics Provider
Choosing an analytics provider is important. I have two rules for it:
You should be paying them money.
They shouldn’t be using your data for other things like selling ads.
Since Glassboard is an inherently private service by default both of these are essential. All of our board information is encrypted on the servers so that prying eyes can’t pry. I want to understand my user base (in an anonymous fashion), but I don’t want those users to be pawns to be used for a marketing company to sell ads off of.
Right now I am using Localytics, but I’m in the process of switching to Keen, because I haven’t been getting the value out of Localytics to justify its $500 price tag. Keen’s pricing and feature set seems much more promising to me. Mixpanel is probably the other major player in the mobile analytics game. They offer some powerful functionality as well.
Each of these services is going to likely run you into the hundreds of dollars range if you have a marginally successful application. The obvious goal is to be able to use the information you garner from these analytics providers to make informed decisions to help you grow your app’s reach and in turn drive more revenue your way.
Vanity vs Useful Analytics
If you’re just focusing on the vanity analytics such as how many users you have, it’s very unlikely that you’re going to get your money’s worth out of any third-party service. What do I consider vanity analytics?
Active users
Usage regions
Amount of a certain type of data created daily
Device breakdowns between iPhone and iPad
This is useful information, but it’s also pretty easily to generate yourself for much cheaper. Alternatively, it’s something you can just check periodically rather than something that needs care and attention on a constant basis.
The real power of analytics comes when you start to understand how your customers are using your app.
How long are they staying in it?
How many people are viewing your upsell prompts? How many are converting?
What’s the average time between a new user signup and the time they start paying for the product or service?
You get the idea. These are hard questions to ask and creating the tools to generate that sort of data is non-trivial. But, when you can start to understand how long someone is staying in your app, you can start to adjust the design of the app to either increase or decrease that engagement.
If you aren’t getting a high enough conversion rate on your premium upgrades, you can start tinkering with the wording or page layouts to see if that will either increase or decrease your conversions.
If you’re getting a bunch of non-paying free users, you can use data to start to understand why they aren’t paying. Maybe your free plan is too generous? Maybe they are just downloading the app and never using it after that first launch? Maybe they are just cheap?
Analytics Through Customer Feedback
Automated usage analytics is a useful metric to have, but far more useful is understanding your user base personally. When I first took over Glassboard, I didn’t really understand who the user base was. I knew how big the active base was, but in terms of who was using the product? It was just guesses and assumptions.
The first thing I did when Sepia Labs handed over the keys was to send out a short user survey using Survey.io to all of the existing premium users to introduce myself as the new owner of the service and to get an understanding of how they were using the product.
Glassboard’s premium user base is far smaller than our free customers, but since this is a bootstrapped company, they are the more important customers during the acquisition. I wanted to understand how the people who supported the service in the past were using it so I can continue keeping them happy going forward.
Our premium user survey had a 70% response rate, which was insanely high. It shared with us a lot of useful information about how Glassboard is being used (many ways I didn’t even imagine!) as well as what alternatives people would consider, which is a pretty good way to learn about some different competitors you may not have heard of.
Another thing I implemented when I took over Glassboard was a ‘personal’ email that is sent out to users a few days after they sign up. It comes from my email address and is basically a prompt to gather direct feedback from our newest users.
Hi [John Doe],
I’m Justin Williams, the CEO and lead developer of Glassboard. I wanted to see how things are going so far.
If you have any questions, feedback or need help with anything at all, reply to this email and I will get back to you with a personal reply.
Thanks again for using Glassboard!
I receive a few responses a day from this, which has been really useful for understanding who is signing up for the service, how they are using it, and (most importantly) what they are finding confusing or hard to grok about Glassboard. By far the biggest source of frustration these new users have is the onboarding experience.
When you sign up for a new Glassboard account through the apps, it creates your account and your first board called “[Justin’s] Board”. It then drops you into an empty news feed. Hardly ideal.
The feedback I’ve received from many users is that they are confused at this point, which is really good personal data. It shows that I have an opportunity to improve the onboarding experience to hopefully receive a more positive response about functionality in the future. We’re working on it now.
Always Keep Tweaking
I’ve been sending the email above for the last few months, and the value from it has diminishing returns at this point. I’ve recently noticed a pretty major influx of new users coming onto the service, but I don’t really have a good idea where they are coming from right now.
I’m thinking my next goal for these new user signup emails will be to just plainly ask users to tell me where they heard about Glassboard and what they are using it for. I may get less of a response back, but the data that does come in will be interesting to see if the understanding I have of my audience from earlier this year still matches the new users signing up as of April 2014.
Data is only as useful as it is current. Long-term trends are meaningful in some use cases, but when you’re in the middle of trying to turn around a ship as big as Glassboard, the past isn’t nearly as important as the present. Understanding your current users is essential to being able to build and sustain a successful product in this new app economy.
The simpler devices get, the more complex our jobs as developers becomes it seems.
When I first started my independent developer career way back in the dark ages of 2006, building an app usually meant building a desktop product that persisted data locally. In some cases there was an Internet backed service tied to it, but it wasn’t the norm. This was before Dropbox, people.
If you truly wanted Internet connected services, you built web apps. Using a mix of HTML, CSS and a sprinkling of Javascript you could build web pages that could replace your desktop apps with something that could run on any device and any browser.
Once mobile came on the scene, web apps weren’t as ‘sweet’ a solution as some would have liked us to believe. The pendulum swung back towards native app development, but with the added bonus of being network connected at all times.
For an app that connects to a third-party service such as Dropbox or Twitter, always-on connectivity means implementing a third-party API in your app and using that as the foundation for your data access. It’s a little more work than our desktop days, but certainly not that big of a hassle.
Fast forward to 2014 and you’re starting to see convergence of mobile and those web technologies. Mobile apps from smaller developers are starting to offer online services either as a value add (such as the wonderful Day One app) or as the foundation of the service (such as Glassboard or soon-to-be from Vesper).
Mobile apps requiring their own custom backend data isn’t new for many operations, especially those with a large staff and a bankroll of venture capital money to burn. For the mom-and-pop shops like Second Gear and Q Branch, it’s a whole new world that just became more feasible just recently.
So, what changed?
App Pricing And Expectations
When I released Photos+ last year, one of the biggest sources of feedback I received was “where is the iPad version?” Nevermind that I just spent several months perfecting the iPhone version, consumers expected that the app would be run on all their iOS devices.
Beyond just expecting your app to run on both an iPad and iPhone, users also expect that data to sync effortlessly between those devices.
Implementing that amount of functionality isn’t impossible, but at $2.99 per app or so it becomes really hard to make the economics work in your favor. If you can instead sell a service for a monthly or yearly fee, however, and then give the apps away for free it becomes a bit more feasible to make the economics work. Still difficult, but at least less of a crapshoot.
The Cloud!
Everything is in the magical Cloud now. All your files are on Dropbox. All your photos in Photo Stream. Everything else in Evernote.
Cloud computing has eliminated the need to be a sysadmin and host your own server hardware in favor of renting resources in the cloud. Amazon, Microsoft, and Google are the big three and are all jockeying to lay claim to all the CPU and storage on the web.
Glassboard runs on exclusively Microsoft Azure. All user data is encrypted and stored in Azure Table Storage. Images and videos live in Azure Blob Storage. The actual platform app itself runs on an Azure Cloud Service, which makes scaling as easy as adjusting a few sliders on the Azure web site.
Backend as a Service
Take the cloud computing paradigm, and simplify it even further and you get Backend as a Service. With a BaaS provider such as Parse, Google App Engine, or Azure Mobile Services, you don’t even have to worry about provisioning resources on the cloud. Instead you just import an API wrapper into your mobile app and configure a few cookie cutter options on the BaaS provider’s web site.
These providers make cloud-enabling your product incredibly simple. The tradeoff of using one versus the more traditional ‘cloud’ is that costs rise exponentially much quicker. It’s a tradeoff that many are willing to make, plus competition has made pricing a bit more competitive than it was even just a year ago.
The Parts of a Platform
We’ve accepted that running our own server-side resources is becoming a reality, we should analyze what that really means. And more importantly, understand what is involved.
1. The API
The brain of that powers any cloud-enabled service is its API. It doesn’t matter what language you write it in as long as its secure, stable, and reliable. Glassboard started out as a full C# product, but I’ve been rewriting parts of it in Node where it makes sense.
Most of the time your users won’t see your API firsthand, unless you offer it publicly as a value add to your customers. Whether it’s a public API or not, versioning from the start is always a good idea. You’ll inevitably get to the point where you want to add or change your API’s functionality. By versioning your API from the start, you can ensure that legacy clients aren’t immediately cut off as you improve your product.
If you’re running a marginally successful service on an API, it’s worth your financial and time investment to look into services like New Relic and Runscope. New Relic does magic things to figure out bottlenecks and other slowdowns in your API clients. Runscope is an API monitoring service that lets you test the health of your API as you run a suite of tests against it.
2. The App(s)
Whether its iOS, Android, Windows Phone, or OS X, the app is the nut of any platform. It’s what your consumers will predominantly use to interface with your service and will shape their opinion on it.
This is likely going to be where most of your time is spent, assuming you want to build something that stands out in such a crowded market. There are plenty of hybrid app solutions that can get you on all platforms quickly, but quick doesn’t necessarily mean quality.
Glassboard has native Android and iOS clients. Each one is built using the system-specific APIs and designed to look and behave like a first class citizen on their respective platform. It’s far more work (and cost) than the hybrid approach, but I believe a better app experience in turn leads to a better conversion rate to paying customers of the service.
3. The Management Backend
This is the one most people forget. Once you’ve developed your API and built the app(s) to consume it, you likely have a user base that is going to be emailing in support requests and bug reports. Those requests likely mean you need to look into the data stored on your backend.
You aren’t an animal. Running raw SQL queries from the Terminal is neither safe, nor ideal. You need yet another app for your platform. The only difference is that this one is for internal use only.
The admin portal is the piece that most developers forget about until after they’ve shipped, but it can also be one of the most important part of your product once you reach a level of success. Let’s imagine you outsource your support to a third-party company (I recommend and use AptFolk). Ash and crew are a smart group, but they don’t know the internals of your product or how to connect to your servers. Nor should they need to. By offering a web or mobile app that allows them to look up and adjust account information or whatever else is relevant, you’re making your job easier.
Beyond just support, metrics are essential to measuring success or failure. There are simple vanity metrics that are useful for showing on an app like Status Board:
Daily signups
Active users
[Your Specific Data] created
Daily/Weekly/Monthly Revenue
For more advanced metrics, I recommend a third-party provider that specializes in things like customer segmentation, funnels, and other more advanced functionality. I use Localytics, but I’m actively shopping for an alternative. Mixpanel is also a nice service, but gets expensive real quick.
Every Piece Matters
The good news is that even though our jobs as app developers is becoming more all-consuming, the tools that enable us to do this are becoming far easier to use. I couldn’t imagine running my own servers back in 2008, and now I don’t have to. Cloud computing takes care of the heavy lifting and let’s me focus on the product itself.
Just because I don’t have to worry about imaging and provisioning servers doesn’t mean I can slack on other parts of my product’s development cycle. The API, apps, and backend platform are all equally important pieces of the puzzle that defines your product. The app may be the only public facing one, but without the API it doesn’t exist. Without the backend management portal, supporting your user base becomes a nightmare that impedes development.
Treat each piece of your product’s stack like it’s the most important, user facing portion bit. Quality isn’t just mean for the surface.
The Full Stack App Developer
Whenever I look at job boards, I notice that a lot of web development jobs are wanting someone who is a ‘full stack’ web developer. To me, that means someone who can build the front end of the application using HTML, CSS, and Javascript as well as the backend using whatever server-side framework is in there. To top it off, sprinkle in a bit of knowledge on cloud computing.
The ‘full stack’ paradigm is starting to make its way to app development going forward as well. It’s no longer enough to just know how to write code for a single platform. To be truly relevant and valuable you need to have an understanding of API design and implementation and cloud computing as well.
Ignoring the cloud or web services because they are out of your comfort zone is no longer an option. The app economy is shifting. Adapt or die.
If there is one thing I don’t think I excel at as a business man, it is making money. That’s probably not a good thing to admit publicly, but it’s reality. In fact, I’d argue that I’ve gotten worse at making money in the past several years as the third-party software market has bottomed out. Making money was hard enough selling $25-$40 products. Try doing it when your most expensive app is $4.99.
The first step towards recovery is admitting you have a problem, and this is one that I am working on this year as I am steering Glassboard towards its next phase of life. I have to. This was December and January’s membership revenue and operating expenses:
I won’t share the exact dollar amounts, but yikes, right? If there’s any solace in those numbers, I was able to make a decent amount of progress between December and January in cutting costs and raising revenues.
Making money is harder than it seems. Most people assume you put a product out and people instantly find and support it. The reality is that for most products, they first struggle to find an audience, and secondly struggle to find an audience that’s willing to pay.
I have an inherent advantage by having a decent online following, which gives me nice starting ground of users to sell my wares to, but that’s by no means a guarantee of success. The goal of making money is to convert people outside of that base into paying customers. That is a problem I’m hoping to solve sooner rather than later.
So, how do I get good at making money? There’s a few different ways I can approach it.
Use Someone Else’s Money
This is what I’d argue is the ‘standard’ way of doing things when you are running a multi-platform service such as Glassboard. You spend a decent amount of time building a pitch deck and shopping it around to a variety of venture capitalists who will hopefully provide you with enough money to give you the resources you need to grow.
This is the least appealing to me for a variety of reasons.
For one, raising money is a full-time job and any time I spend running around begging people to write me checks is time I’m not spending on the product. Second, I don’t see it as a good fit for the type of business I want to run. Venture capital is for people who want to grow something to Instagram or Tumblr levels. Getting funding for something that VC typically (and insultingly) refers to as a “lifestyle business” is far harder. Glassboard, by design, isn’t designed for those insane levels of scale.
And finally, I’m personally averse to the whole racket of venture capital. Entrepreneurs are the new labor, especially when old guys with money are funding the sweat of someone who gets to put “founder” on their business card. I’d rather not participate in that.
VC is a nonstarter.
Cutting Costs
The easiest way to make money is to spend less of it so that your monthly profit-loss is heading in the right direction. By cutting costs, it’s easier to approach the break-even or profitable point.
This is the way I have been approaching Glassboard so far into my tenure. The existing service had quite a bit of fat on the edges that could be cut without impacting the service in a negative way. Some of the things I did were:
Negotiate a new plan with Sendgrid to account for how much email Glassboard sends on a daily basis (well into six figures). This 30 minute meeting shaved over $1000 a month off my monthly expenses.
Disable email on any board that has over 200 members on it. There are not many of these high traffic boards, but they accounted for a heavy portion of our email traffic. I’ve had maybe 2 complaints about this since I changed it six weeks ago.
Optimize Glassboard’s Azure Cloud Services to dynamically scale the amount of instances it needs based on how much traffic is coming in. This shaved about 40% off the CPU costs on my monthly Azure bill.
There’s still plenty I can do to cut costs, but that only solves a small portion of the equation. None of the remaining items on that list are on the low-hanging fruit/quick win list.
The far more interesting opportunities are actually increasing the monthly revenue.
Increase Revenue
Duh, right?
For apps increasing revenue can be done by raising your app’s cost, adding advertisements, or inserting some sort of in-app purchases. Every app is different, so it’s hard to offer a single prescription for success to everyone. I can only speak to my use case.
For Glassboard, this is the hard nut to track because I’ve got tens of thousands of users who have been using a service for free that I have to figure out how to bring revenue in from.
One of the first things I did was lower the cost of a Glassboard Premium subscription from $50 a year to $25. There was no science behind this decision other than me personally not being willing to pay $50 a year for the service. $25 sounded much more reasonable for the existing offerings.
I also added the yearly premium subscription to the iOS app as an in-app subscription, so that it’s easier for people to support the service.
Neither of these changes set the world on fire. I sold more Premium subscriptions in two months than Glassboard sold in its previous two years of existence, but it was also at half the price.
The more interesting metric I discovered was how many people weren’t even aware Glassboard had a paid offering. Since people primarily access it through the iOS and Android apps, they had never been prompted to pay for the service. I had more than a few complaints from people about adding the premium subscription as an option in-app. These are the folks I assume will never be customers.
There’s still plenty of existing users to try and convert to paid, but $25 a year is a hard sell in 2014 when $1 apps are seen as the new Premium. The next phase is experimenting with different business models and ideas as I try to get better at making money.
I’ve got a few ideas. Now to just build them out and measure the results.
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.
