A Guide to Creating Your First SaaS Knowledge Base

If you're reading this you're probably familiar with what a SaaS (Software as a Service) company is. Maybe you've founded one or you might work in the customer support team at one.

The big appeal of SaaS businesses is the way they scale. Unlike brick-and-mortar stores, you don't need to buy 100 seats and 50 tables for people to come in and enjoy your latest artichoke recipe 🧑‍🍳👌

It's so much easier to get a database up and running than set up a restaurant and keep service going 6 days a week. You don't even need to leave your sofa. You can leave your joggers on and wither away with nothing but ice cream to sustain you (not recommended regularly but totally fun sometimes).

With the right knowledge you can then scale and build a business worth millions (or a tasty $27.7 billion if you're Slack) without the cost of setting up physical stores across the world. And that's exactly why the SaaS industry is estimated to be worth a whopping $307.3 billion by 2026.

There's always a catch though. The best thing about SaaS is also the worst thing about SaaS.

If the business model scales so well and provided you pique enough interest how do you deal with the influx of customers? It might sound like a good problem to have but in reality, it's a huge headache.

This is where most SaaS businesses get stuck in the scaling phase. Adding 7-10% month-on-month sounds impressive on paper but when the servers and support team are struggling to keep up it can end in downtime and disappointment.

And this is where a Knowledge Base comes in handy. Instead of answering repeat questions in individual support tickets you can write the answer in a more general way to hundreds, thousands, or millions of people.

"I'm not here to shill you a Knowledge Base. It's not a golden goose and it absolutely won't solve all of your problems."

There's a good reason Google put their knowledge base front and center and make it so difficult to get in touch. The same goes for Apple, Microsoft, and Netflix.

In this guide, I'll help you work out whether you need a Knowledge Base for your SaaS, the different types of Knowledge Bases, and how to get started when you've picked the right one for you.

Why Bother Creating a Knowledge Base?

I've mentioned some impressive numbers for SaaS in general but why create a Knowledge Base? Surely you can hire support agents in-house or outsource them? Isn't live chat and bots enough?

I'm not here to shill you a Knowledge Base.

It's not a golden goose and it absolutely won't solve all of your problems. And I understand your frustration because it feels like we're all being pulled in all different directions when it comes to customer support software.

Get posts in your inbox, monthly.

Bookmarked Monthly is a free newsletter covering the art & craft of knowledge bases and customer support while delving into the lives of the people behind them.

Subscribe

The main reason to green light setting up a Knowledge Base is to reduce support volume. While an FAQ page will help in the short term there will inevitably be a time when it gets out of control. No customer wants to scroll through a list of 100 questions.

Here are the main benefits we've found for a SaaS switching to a knowledge base.

You can help users take shortcuts with built-in search

If you take another look at the 4 examples from Google, Microsoft, Apple, and Netflix I showed earlier you'll notice a common theme—they all have a prominent search bar.

We humans don't like to waste time and tend to only stick around on a web page for 10–20 seconds unless it provides some clear value. And what's better than a big ol' search bar? It's an advert that screams "skip the scrolling and find what you need with a few words instead".

Obviously the search needs to be somewhat reliable if you're gonna expect users to try and find your help content but it's a big win comparing it to a list of question-and-answer style accordions for users.

Organization helps users with content consumption

We all do our best to be organized. I remember when I'd start the school year with the highest hopes.

I would get a swanky new pencil case, a set of the fanciest ballpoint pens, and a crisp notebook to start with a clean slate. After a few days despite my best intentions, my pencil case would have marks all over it, my pens were lost forever, and my notebook was crumpled with creases.

An FAQ page is a bit like a new notebook. Despite best intentions and trying to cover all bases most people won't read them. We've become a society of skim-readers who want to find the content they're looking for.

By having your Knowledge Base content in neat little folders (in our case we call these categories) people can skim and click to filter the content they're looking for rather than needing to read line-by-line.

Find out what's working and what's not with analytics

Every eager marketer loves analytics and there's a good reason for that. Analytics give you insights into how everything is going. Did that webinar help increase signups? Do those emails decrease churn?

"Not only does this help you optimize your self-serve support, but it can help folks over in product and sales answer questions"

Customer support analytics tend to mark performance with metrics like response time, the number of tickets responded to, and ticket resolution time.

And just like support ticketing software, Knowledge Base software can give you answers to questions like:

• Which articles are the most popular right now?
• What are our customers searching for?
• How many people are getting in touch after scrolling through our articles?

Not only does this help you optimize your self-serve support, but it can help folks over in product and sales answer questions like:

• Are customers interested in learning how our new feature works?
• Do customers understand how the new feature works after reading the documentation?
• What questions are prospects searching for when thinking about starting a trial?

Analytics inside your Knowledge Base software can unlock important insights into what customers are looking for and whether they're finding it.

Building vs. Buying

The majority of SaaS teams have talented engineers, so the elephant in the room is whether to build your own solution or trust someone else to host it.

That's a fair question and one that's not always obvious. Let's break down some of the pros and cons of both options:

Build-it-yourself

Buying a hosted solution

These are just a few of the pros and cons for each options. One factor to consider is how complex the solution you want to create is and whether a hosted solution can accommodate that.

"If you've got a support team who need to collaborate on a system and you don't want the hassle of hosting it yourself, a hosted solution makes a lot of sense"

Let's say you wanted to pass on API keys and sensitive information through to your Knowledge Base if the user is logged in. That might be a good case to host it yourself.

Or maybe you want to host a simple FAQ page for customers to view with a few accordions. Building out a complex system while you're not out of private beta isn't a smart use of time.

However, if you've got a support team who need to collaborate on a system and you don't want the hassle of hosting it yourself, a hosted solution makes a lot of sense.

Start Creating a New Space for Your Support

Now the exciting part—creating a new space for your Knowledge Base. This place is where your customers will end up first so it needs to be accessible and match your wonderful brand.

It's your domain

Whichever hosted Knowledge Base solution you choose, you'll probably end up with a subdomain to start with. Ours end with .helpdocs.io so for our own support page we chose support.helpdocs.io (we got first dibs of course 🙃).

Anyhow, that doesn't matter too much because you'll likely end up adding a custom domain to your Knowledge Base. This tends to be one of the first things a team will do once they've zero'd in on which software to use.

Most of the time teams will go for something like help.yourmaindomain.com or support.yourmaindomain.com—it depends on your style. If you're feeling adventurous you could even think up something more unique.

Who and what?

Knowledge Bases work best when you collaborate as a team. Inviting your team and empowering them to write & update articles is probably the best thing you can do as a support manager since it'll:

• Reduce repeat support requests
• Help your support folks understand the product better (teaching is the best way to learn after all 😉)
• Give product team members the chance to make quick updates on the fly

With a hosted Knowledge Base you can restrict and allow certain access. At HelpDocs we have a concept of roles, so some people can fiddle with Settings while others can focus on writing articles.

Brand it to be yours

Giving customers are consistent experience across your various channels is a priority for SaaS businesses. Your Knowledge Base is no different.

You've probably noticed we kinda love pink and so our Knowledge Base has accents of pink. With a logo and our brand color our self-serve support fits snuggly without having to make any customizations (we have brand tools like adding your logo and brand color to make it easy 🧘).

You can also add more of your uniqueness by adding your regular navigation at the top or customizing the style of buttons and links.

Don't go too far down the rabbit hole though—keep it simple by using built-in templates. Going all out and using your developers' time to create a template from scratch could cost a lot and take away from your main offering.

Audit Your Features

So far you've probably used an FAQ page or you've been going along trying to keep up with product features that your team is releasing.

Auditing your features is probably the best way to ensure you create a well-structured Knowledge Base. Without a plan, you might end up with repeat or articles that confuse customers and mess up your search results.

So how do you start with a feature audit? It depends heavily on your SaaS product but here's some advice.

Start by identifying areas

As your service is likely split into areas whether it's an in-app experience or a website, your best bet is to split out features into areas.

This will help as only certain users will have access to certain areas too. For example, customers will have certain plans or have different roles.

Our app is split neatly into different areas, so I would split by:

• Settings
• Content
• Audit
• Clips

Start writing down features in each area

The next step is to look at each area and start going through each feature thoroughly. This will allow you to map out what you need to write about.

Here's a quick example from one of our Settings pages:

• Settings > General
  - Contact forms and contact form email
  - Custom domains
  - SEO title & description

You get the idea—you'll want to make sure you write down each possible feature so you can cover it in your Knowledge Base and group them into categories and subcategories.

Jobs to be done

If you've worked in SaaS for a while you've probably heard of the Jobs to Be Done framework. If not, it's a way of thinking about what "jobs" your customers are trying to achieve with your feature or marketing material.

It applies to your Knowledge Base too. If you think about it, your customers are trying to learn how to use your product when they come to your Knowledge Base.

Recently my Apple Watch didn't turn on after my incessant tapping. So I Googled "Apple Watch not turning on" and viola! Apple had a Knowledge Base article all about it and I got it working again.

"By splitting your features out by jobs you'll be able to create themes."

The main job of a Knowledge Base for a customer is to answer a question like "How can I add an image to an article?". For support folks, it's about reducing support tickets and increasing retention.

If you look at our Knowledge Base you'll notice a theme of Jobs to Be Done.

Newcomers will want to get set up right away and so we give them the information they need in the Getting Started category. Others, further along, might want to focus on making their Knowledge Base their own and so the Customizing Your HelpDocs category is there for them.

By splitting your features out by jobs you'll be able to create themes.

Here's another example from Wise.com who help people transfer money around the world:

Their categories are split out based on what their customers might want to achieve. Sending money, changing their account information, ordering or activating a card, and so on.

Creating a Flow for Your Team

Article Repeatability

Since you'll be creating so many articles and collaborating on them as a team, repeatability is the key to success.

As a base for your article, you'll want to create a template that everyone can follow so no matter who's writing the articles, they're consistent and in the correct tone.

We use our Clips feature to start different types of articles. Here's an example of our Clip for an article about an integration:

[PRODUCT] [DESCRIPTION]
By enabling [PRODUCT] on HelpDocs, you'll be able to:
1. THING 1
2. THING 2

Repeat title
Video/image
1. Step 1
2. Step 2
3. Usually Hit Save

This ensures all the articles in the integrations category have the same structure. Lovely jubbly.

Integrating it into your workflow

Having a system in place with your own tools will make it so much easier for you to keep on top of new articles to write or old articles to update.

Whether you use a team to-do list like Asana or an issue tracker inside GitHub, creating a Knowledge Base does take effort, and bringing your team on board makes the process a whole lot more simple.

When writing feature or roadmap docs, keep Knowledge Base articles top-of-mind by creating to-dos in the final stages. You don't need to leave writing the Knowledge Base article until the end either—you can write a draft with a few notes inside and leave it until later to fill out (this is pretty slick with our Chrome extension 😘).

Keep it Simple and Start Building From There

In my experience, many SaaS companies tend to think too much about the design and less about the usability of their Knowledge Base—or worse still, the content.

Is design an important factor in a Knowledge Base? Absolutely. But you don't need to be spending hundreds of hours on custom templating right away, or custom formatting inside your articles. A little custom CSS or JavaScript can usually do the trick ✨

Map out your features, write simple articles, organize them nicely, fit your Knowledge Base into your workflow, and customize it to fit your brand.

Interested in learning more about updating your SaaS Knowledge Base with your team? Check out our guide below 👇

Ship & Sync: Keeping Your Knowledge Base Updated Alongside Your SaaS Product - HelpDocs

You’ve got a great SaaS product but how do you keep your knowledge base accurate when you update it? In this guide we’ll go through some strategies you can use as a customer support person, engineer, and product manager.

HelpDocsHelpDocs