Automating a Business

We have recently started a very interesting project with Tyler Tringas to help him automate his Micro-SaaS company StoreMapper.co. We will document and publish our progress and results here as a case study.

You can follow along and get behind-the-scenes updates here as well as on Tyler’s blog. Read his post Putting a Micro SaaS Business on Autopilot where he laid out his current situation, strategy, and motivation to work with TightOps.

Transparency

There are many fascinating aspects to StoreMapper as a business. Particularly interesting is the fact that Tyler decided a while back to be transparent about money, which means the live financials for StoreMapper are public.

Update: The baremetrics dashboard is no longer available. Tyler has successfully sold the business.

Tyler is also writing a book about Building a Micro-SaaS Business. As putting the business on autopilot would make for a great later part of telling StoreMapper’s story, we thought it would be a great opportunity to work together and let our readers know about how we approach this and what kind of results we are getting.

Case Study

Following the usual case study format, I will lay out the situation as we have it at the start of the project (aka the problem), then start adding the strategies and solutions we are applying, and report on our results.

Starting Situation of StoreMapper.Co

StoreMapper, “A dead simple store locator widget”, is a focused business, stripped of unnecessary complexities. That makes it an ideal object for full automation. It’s more like one single department of any other business. This also means that what we’ll be doing can be extrapolated to larger, more complex business.

Until a few months ago StoreMapper was a one man show. Tyler had developed the core software application, run customer service, and did basic marketing.

Recently Tyler has hired his first employee for customer service and brought on a freelance developer. We are going to look at the customer service process first, development second, and the connection of the two third.

Customer Service Automation

Customer service at Storemapper.co runs through Intercom.io, an app that allows the customer service team to keep track of conversations with customers.

As it was Tyler who was answering all incoming requests in the past, there are many conversation to search for similar issues and check how they were resolved. And that’s exactly where Chris, the new hire, has been checking for answers.

Now, having these conversations as an improvised “knowledge base” is not an ideal solution. We rather wanted to start building a new, comprehensive one that we can use to publish support articles regarding specific questions and also have an internal part where we keep all the work procedures (SOPs) for the support team.

Technologically we are using a Wordpress blog with a plugin that allows us to have non-public articles for the team, plus a growing number of public support articles for the customers. You can see the public support blog at storemapper.com/support.

It’s a self-improving customer support process, as demoed in this video at about 01:00 minutes):

So, what’s next? Simple: we need to move know-how from inside Intercom and from Tyler to the blog. There are existing articles and we will add to them. After all, every support issue that the customer is able to solve by herself is one less to work on for the support team. It’s delegation all over again, only this time the support team delegates the work to the customers (which also saves the customer time in many cases).

Bring in the SOPs

It’s also time to get more specific and introduce our first standard operating procedures (SOPs) to get proper instructions/documentation for how to solve specific issues. For more information on business process documentation, including templates and examples, see our business process guide.

We’ll share some of our SOPs here in the future.

Error Alert Handling

As early as in our onboarding call we talked about the need for a solid process to handle error alerts. After all, if you have to be on call at any time because an error might occur and you are the only one who is able to solve it, that weighs quite heavily on you, … well, Tyler in this case.

My perspective here is this: The subjective need to be on, online, or available all the time is a nagging problem to have. Even in a scenario where you don’t need to work in the business, the simple fact that you have to be reachable keeps things still dependent on you.

Error alerts are a real thing for any software as a service company. Your customers expect the service to be working. If and when there is an issue, the time it takes to get everything back up and running is crucial.

And here’s the real-life scenario: Tyler is about to visit Africa. A perfect opportunity to set up our “Error Handling Guidelines”. We will define

the different priority levels of errors,
who to notify, and
what to do about it.

We are pre-planning for the situation where Tyler can’t be reached, so it’s clear for the team how to decide on what to do and execute instead of getting paralyzed and indecisive.

Test Successful!

Here’s Tyler:

Hey Nico. I’m more or less back on the grid. In Zanzibar but have wifi. First test run of off-grid-founder went pretty well! I was completely out of touch for 6 days hiking Kilimanjaro, back on for about a day and a half, then off again for 5 days. We had almost no issues during the first stretch and only one apology-email-worthy issue on the second stretch. So far even that customer is still with us. I think we net added about $400 in MRR over the two weeks.

Not too bad!