← All posts

How we scaled support for 4,000+ subscribers and 1,000+ monthly trials (without dedicated support personnel)

• Written by Marko Saric
Scaling customer support as a bootstrapped SaaS

We’ve grown from less than 100 subscribers to more than 4,000 subscribers since April 2020. With all this success also comes a growing volume of support requests.

We recently started onboarding a new team member to help us with customer support. This is an excellent time to look at how we dealt with CS as a two-person bootstrapped startup and managed to support 4,000+ subscribers, 1,000+ trials per month and a growing open source community before looking for any help.

  1. The importance of customer support
  2. Scaling customer service without degrading the experience
  3. How we deal with customer support
  4. All the fancy tools we use for customer support
  5. Common customer questions become a priority
  6. An up-to-date and detailed documentation is a must
  7. Link prominently to the docs and make them easy to find
  8. Frequently asked questions on the contact page
  9. Teach and share knowledge through your content
  10. Don’t give people a reason to have problems with your product
  11. Be flexible in things you work on
  12. Self-hosted support should be mutual
  13. Not being able to disconnect and get some time off
  14. What other steps could we take and what could we get better at?

The importance of customer support

You cannot ignore customer service as a bootstrapped startup. Customer support experience is a significant part of the overall brand experience. Some people may decide not to go with your service if they get poor support. Some may be so annoyed they talk about it on social media and on review sites.

A fast and personal customer support experience can make people share positive stories about your brand on social media. Plausible rejects to pay Google and Facebook to do the marketing for us so we rely on word of mouth from people who enjoy our product to help us spread the message.

These are the people who pay our bills and people without whom Plausible wouldn’t exist. Being able to interact with them, accommodate them and make their experience better is very crucial to us.

While at university, I had a part-time job at an online gaming company doing customer support. This was useful in giving me some real-world experience, providing some cash for my student life and taught me an important lesson.

I believe that every team member, be it a founder, a developer or a marketer should get regular experience dealing with customer service to better understand the product they’re working on and the customer they’re serving.

People that answer customer support questions understand your business the best. They hear from prospects and customers all the time. That’s their job after all.

They know what the frequently requested features are. They are familiar with the annoying bugs people complain about. They understand what competing brands people compare the product against.

This means that customer support needs to be in very close contact with the rest of the business if you want to provide an outstanding product and user-friendly experience. Luckily for us, we’re a small team so everyone does customer support regularly and there’s no disconnect between CS and the rest of the company.

Essential insights that should be prioritized and doubled down on will come from customer support. You will not need much market research if you simply listen to what your customers tell your support team.

Scaling customer service without degrading the experience

The vital fact to stress is that we’ve scaled our customer support to these levels without degrading the customer experience. People still get fast responses from real humans and people get a personal experience too.

I have the habit of skimming a few of the articles that rank on top of search results for every blog post that I write. Top ranking posts for scaling customer service are full of user hostile tips. I’m glad that we don’t use any of the “best practices” for scaling customer support:

  • We don’t use any no-reply email addresses
  • We don’t use any automated AI chat bots that engage people
  • We keep all of our contact details easy to find
  • We allow people to contact us wherever they prefer, be it via email, GitHub or social media
  • We don’t do any prioritization according to the subscription tier or customer lifetime value. All responses are pretty much first come, first serve
  • There are no endless waiting times to hear back from us. Most people writing during working hours European time hear back within minutes

How we deal with customer support

As in every early-stage startup, any role is fluid and you work on what needs to be done. In Plausible, customer service is my responsibility alongside other marketing and communication tasks.

We allow people to contact us on any platform where we’re active. People reach out to us via email, via GitHub, on Twitter and Mastodon too. I aim to answer all emails and messages as soon as possible and pretty much every day I can finish at inbox zero before logging off.

Getting back to people quickly is probably the most important thing you can do when it comes to customer service. We frequently hear back from people being delighted at how quickly they get responses to their questions and can get on with their Plausible journey.

I respond to most of the messages but sometimes if the question is too technical so that I don’t know how to answer it, I get my co-founder Uku involved to answer those questions better.

We try to offer a great service to all subscribers and not only to important prospects. There are no sales calls and no wining and dining as part of the onboarding process.

I have had to politely decline one request for a full day of meetings and a long vetting process with one corporation that was exploring Plausible.

We exchanged a few emails, had a quick call and then updated our publicly available documents to make sure all their questions were answered so anyone else could benefit from those answers too.

This may be disappointing to some that are used to deal with startups through demo calls, PowerPoint presentations and sales representatives. Treating everyone fairly and equally is the only way we can manage it as a bootstrapped startup that’s limited in resources.

All the fancy tools we use for customer support

We use pretty much no specialized CS tools to help us deal with questions from users. This is what we do use:

  • We switched to HEY for Work to make the process easier and faster when communicating with each other. Before, we were forwarding emails or using messaging apps to discuss specific cases. HEY allows us to talk privately within an email thread instead. This saves us time and makes the process smoother and easier to deal with. No one has accidentally sent an internal message as an actual reply until now :)

  • HEY makes other things easier for me too. I keep all the emails to respond to in the “Reply Later” section and I keep all the emails for which I require some information before I can respond in “Set Aside”. HEY also has this great “Focus & Reply” functionality that allows me to reply to all the “Reply Later” emails on one page without any distractions. And I love the fact that I can bundle say all GitHub messages in one thread.

  • I use a clipboard manager on my Linux laptop to track the canned responses to the most frequently asked questions. I have about 50 on my list. This makes it simple to copy the answer and paste it into an email reply. Then, after a moment of work on personalizing the email to the relevant situation, it is ready to be sent. Without this, I would have to retype similar responses often which would slow me down dramatically. We had the same canned responses setup at the gaming company I mentioned earlier.

  • I use TweetDeck to deal with all the incoming mentions and other messages on Twitter where we have a growing audience. TweetDeck allows me to get a distraction-free experience in which I can hide any likes and retweets not to get too overwhelmed. I have several columns in there including one for mentions, one for direct messages and another that searches for people talking about Plausible without directly tagging us.

  • One trick I use is to search Twitter for people talking about Plausible without @ mentioning us. This way I find people that say Plausible Analytics, plausible.io or share our blog posts. I can then interact with them. I would miss out on these tweets if I just looked at our notifications.

  • We have a simple, self-hosted CRM called Kaffy. It gives us the basic info about a subscriber such as when the account was created, the status of the account, the email used to register and sites added to the account. This helps troubleshoot specific questions. We’re privacy-first even in our own analytics needs so have no more data on our subscribers than this.

  • We also have a self-hosted Sentry instance that allows people to leave user feedback in app if they encounter any bugs or other errors. We review that feedback and get back to people that need any help.

  • I also frequently use Paddle, our payment processor, their CRM and their support team for specific questions about billing, invoicing and payments. We let Paddle deal with all of the payment side of things and it is beneficial to have them handle card issues and similar requests.

Common customer questions become a priority

Acting on feedback and improving things is one of the principles behind the development of Plausible.

After initially experiencing an increase in support volume, our first step was to look for ways to be more efficient. We’re self-funded and without any outside investment so we also need to be careful, frugal and focused on sustainability.

Suppose we can solve a common issue by improving our product or by better explaining a functionality. In that case, we choose to do just that rather than ignoring the problem and simply throwing money at it by hiring people to deal with support.

When I notice a similar question pop up often, we act on it by fixing things and improving the app itself. If several people struggle with something, it becomes our development priority.

We may communicate about it better in the app, we may link to the docs or improve the feature to avoid the same issue occurring again in the future.

This also leads Plausible development to be focused on fast, simple to use and easy to understand solutions. If we can release a feature that is obvious and it just works, it will lead to a higher level of customer satisfaction and no difference in support volume.

The product itself being minimal and easy to use makes it possible for us to serve thousands of customers and new trials without being overwhelmed with messages.

An up-to-date and detailed documentation is a must

Having a documentation has helped us dramatically reduce the number of questions.

Our docs are the fastest and simplest way for people to get answers to their questions. I put a lot of effort into our docs, spend a lot of time on them and make sure to keep them up to date answering any new questions we are getting.

We use Docusaurus for our docs and the Algolia DocSearch to allow people an easy way to search the docs and find answers.

Having docs also gives me easy answers that I can copy/paste into emails if someone doesn’t check the docs. I also often link to the docs and our blog posts when we get some questions that we have already explained in detail.

When hearing from people, so many have told us how useful they found the documentation. I never understood the value of documentation until I started working on the Plausible documentation. Now I feel it’s a vital part of customer support and recommend it to every startup.

What’s the point of putting so much effort into the documentation if you’re not going to make it very easy to discover?

We prominently share the link to the docs in the top menu for our logged in users. We also place a link to the docs on the top of our “Contact” page:

Our Documentation is a great place for most answers. We put a lot of effort into making our documentation be as detailed and as up to date as possible so you can quickly find answers to any question you might have. Can’t find what you’re looking for in the documentation? Please do contact us using the email address below.

Frequently asked questions on the contact page

Some frequently asked questions with brief responses are also placed on our contact page. If we get a specific question several times, I add a brief answer to the FAQ.

It often happens that when I add a new answer to the FAQ section on the contact page, we pretty much never hear about that question again.

Teach and share knowledge through your content

I’ve published a lot of content since I joined Plausible. A lot of that content has been educational in nature focused on our audience’s needs. You will rarely find a post on our blog just talking about how great Plausible is. In most blog posts, the main topic is something else and Plausible only gets a mention when it’s relevant.

This is the type of content that can help site owners deal with different areas of running a site. It also makes Plausible more of an authority in our niche. Some examples of educational blog posts that we’ve published:

  • When we released UTM tag support, we published a guide on how to use UTM tags to better analyse your marketing campaigns

  • When we released the feature that tracks 404 error pages, we published a guide that goes in depth on 404 errors, why they are important to track and how you can fix them

  • When we released the feature that tracks clicks on external links, we published a guide on why that is useful

  • When all the major browsers made a change to their referrer policy, we had a guide on how that affects all the different web analytics tool

  • We also published a lot of content on the topics of privacy regulations, GDPR, cookies and privacy policies

All these topics are relevant to Plausible, to our existing subscribers and our potential audience too. We now have a lot of links we can share when people ask us about these subjects. In many cases, people don’t even need to ask us anything as they find the answers in our posts.

What’s even better is the fact that these educational blog posts now help many people discover Plausible when they’re using search engines to look for answers to the problems they want to solve.

Don’t give people a reason to have problems with your product

Couple of main areas that generate massive amounts of support load are product bugs and uptime. We do our best to minimize bugs and any downtime.

One of the significant decisions Uku made that helped us scale was to pick the right technology. Over a year ago, our dashboard started getting slow even for sites with tens of thousands of visitors so we switched to ClickHouse as the database. That has enabled us to grow to where we are now.

ClickHouse runs crazy fast, we’re counting more than half a billion page views per month and we’re serving sites with tens of millions of monthly page views (the top site gets 150 million monthly page views) without any issues. Plausible loads faster for a site with tens of millions of visitors than Google Analytics loads for a site with hundreds of visitors.

Our dashboard being fast-loading and accessible at all times to all of our users is a key element that decreases the need to reach out to the support.

We also keep a public status page with any downtime or scheduled downtime clearly visible which is another reason people have less need to reach out to us.

Be flexible in things you work on

The tasks I spend my time on over the last eight months or so since we got all this traction have completely changed.

When I joined Plausible as a co-founder, I spent 90% of my time writing blog posts and doing marketing outreach trying to get people to talk to us. Now I spend 90% of my time on community management, public relations and customer service talking to people that reach out to us.

At first, I wasn’t sure if it was good to reduce the amount of time I spend on proactive marketing activities and spend that time on the more reactive tasks. Now I see it as a natural part of the journey.

The early efforts were focused on increasing brand awareness and attracting people to try Plausible. Now that so many people are showing interest, we better treat them nicely and give them a great experience to stick with us.

People who try Plausible and have a great and valuable experience transitioning from Google Analytics help drive word of mouth and buzz now. So be flexible and understand that this is normal and your role may change as you progress.

I can always get back to doing more marketing if we struggle to grow or when we have more dedicated customer support resources in place.

Self-hosted support should be mutual

Plausible is an open source product. We have a self-hosted version which is about giving back to the community. It’s completely free to use.

Self-hosting does bring a large volume of support questions. Pretty much all of them are highly technical, as managing your server infrastructure is no easy feat.

Questions self-hosters ask have no connection to the questions we get from our subscribers. Subscribers mostly ask about the product while self-hosters ask about server configuration, databases, backup and other things that subscribers don’t need to worry about.

Early on, we tried to deal with self-hosting questions in the same way as questions from our paying subscribers. That turned out to be an impossible task as each self-hosting question highly depended on the individual setup.

We’ve since set the expectations straight and made self-hosted community support only. To provide a better service and experience to people who pay our bills and make is possible for Plausible to exist, we no longer guarantee that we will help out with self-hosting issues. We will read all messages and may respond to some messages but expectations are clear.

If you want a simple, easy and convenient experience, and want to know that you’re helping us make this project sustainable, do sign up for our cloud version where everything works out of the box.

If you want to manage your own infrastructure, do use the self-hosted version but be prepared to troubleshoot your issues, read our documentation or get community support in the forum.

Not being able to disconnect and get some time off

The weakest point of our current setup is the fact that it’s difficult to take any time off and disconnect completely. If we both do that then no emails would be answered and that’s not acceptable.

Until now, there’s never been more work than we could handle for a sustained period of time. There have been some crazy days and weeks but it comes with the territory of being a fast-growing startup. It’s clear that our current setup suffers if one of us goes on holiday and cannot check emails at all.

Since I’ve joined Plausible in March 2020, I have pretty much looked at our email and social media inboxes every single day including weekends. In my previous jobs, I used to take two weeks off and put an out of office message without worrying about anything.

This is much more challenging in a bootstrapped startup and we’re looking to get some help with this. Summer 2020 was easier to skip as we were in full-on lockdown due to the pandemic but we’re hoping to get some time off this summer to recharge. This is one of the reasons why we recently started onboarding Robert to help us with customer support among other things.

Robert is a developer so the idea is for him to also help on the development side of things. Many of our custom support inquiries are technical so it really helps to be tech-savvy person with experience in running a website when answering the questions.

Short term, after a few weeks of training, Robert can help us offload some customer support queries so we can take some time off this summer without being glued to our screens all the time.

What other steps could we take and what could we get better at?

We have several options open to us in the future. We may not use them but it is nice to know that there are solutions in case customer support becomes more difficult to handle:

  • We could introduce support office hours and be transparent about them. I’ve noticed companies setting up autoresponder saying that you can expect responses during working hours on working days only. I was responding at any time be it in the evening or the weekend. It is nice to be able to set some more regular hours so people contacting us know that we may not respond during the weekend.

  • We could funnel all the customer service queries into one place. We could either use a tool that allows us to deal with email, social media and GitHub in one place or we could say no guarantee for timely responses to questions in social media, only via email. This would help not spread us too thin.

  • A large percentage of our support questions are from people just starting out creating their first website. The questions are generally about the integration of our snippet into their site. In the line of “I just inserted your script and visited my site but my visit doesn’t show in the dashboard”. These are routine support questions that require a bit of technical expertise viewing site source or using the browser console to answer. We’re looking to further help people troubleshoot this on their own.

  • We also often hear questions about invoices. In the line of “I cannot find my invoice from July last year, can you please resend it?”. We plan to create a billing section within our account settings that allows people to view and download their historical invoices at any time.

  • We get a fair number of feature requests. Until now, I have tried to follow up with them to inform them that the feature has been released but haven’t really followed through 100%. It would be nice to find a way to categorize feature requests so we can contact all people that have asked for something after the feature they requested is live.

Growing your brand to get more social media mentions, buzz, signups and MRR leads to more emails and questions. Be prepared for it and think about how you can do customer support more efficiently so you don’t get too overwhelmed. I hope our experience helps you a bit with that. Good luck!

Written by Marko Saric

Hi! We are Uku and Marko. We're building a lightweight, non-intrusive alternative to Google Analytics. You can read about our journey and what we've learnt along the way on this blog.