Last updated on Mar 8, 2022
The rise of SaaS in the last decade or so has brought literally hundreds of companies to the status of household name, all around the world.
But they didn’t get there on the strength of their products alone. Customer service and support is what made everything go smoothly behind the scenes – and a big part of that was documentation.
Appropriate user documentation in the right style and in the right place on your website is extremely critical for turning browsers into buyers.
This is because people nowadays really value helpful user content online. After all, how many times have you been frustrated with a website for not including information that should be obvious?
A lot of people are using product documentation software such as a knowledge base to achieve that goal of excellent SaaS documentation.
In this article, you’ll learn about the reasons why good documentation is truly essential to building a strong SaaS brand, plus how to actually sit down and get that documentation done with a knowledge base software.
If you look around some of your competitors’ websites, you’ll notice a couple of distinct themes in design language. Websites nowadays look different than they did ten years ago, and those looked different from what came before.
What’s interesting is that although the websites of 2010 and 2000 probably had roughly similar types of content available to the visitors, the websites of 2020 almost universally have an entirely new section.
Most businesses have shifted to open content docs, so you can see the help files even if you haven’t signed up with the software. Before, you’d read help files in the software itself, or from a readme included with your installation CD (remember those?)
As unintuitive as it might seem to make help files available to everyone, it actually has a bunch of advantages.
Chief among these is where your information is coming from. If you look at the SaaS giants of today such as Salesforce, there are whole forums of power users telling each other how to do things with Salesforce.
Your product might not be as much of a public necessity as that, but the advantage of putting your docs on a website for all to see is that you make it that much easier to trust your own company’s expertise on the topic of product support.
A company that locks off its help docs (or worse, has poor documentation in the first place) risks being taken less seriously than enthusiasts all across the Internet, who can easily slip in plugs for your competitors when talking about how to solve problems with your software.
By keeping everything in one place, you make yourself the authority, and you make others appear as though they’re just copying off the knowledge base articles available for anyone to look at.
The other reason businesses have knowledge bases full of public-facing articles is a little bit more utilitarian: it gets them a better ranking on web search results.
Search engines like content that has a lot of relevant links and a lot of similar, popular pages. Since documentation often gets linked to other documentation pages, this means your help desk articles are natural candidates for good search rankings.
This becomes even more true when you use content-rich page design, with articles containing pictures, code snippets and more. This makes your articles more engaging for searchers, and in turn it boosts the rankings of those pages.
It gets to the point, ideally, where just one keyword search for something your product can do turns up more than one page result from your own documentation right on the first page of Google.
You might be thinking, well, this is what content marketing and other interesting bits of the website are for. Why should documentation fill this role?
Why Documentation is Critical for SaaS Companies
Let’s face it. A lot of SaaS companies make good software, not great software.
There are so many different startups on the market right now that the core features of any one of them are liable to have been duplicated not out of any sort of corporate espionage, but just because there aren’t that many more unique features available to invent.
The real reason people use one platform over another is the service part of SaaS.
It’s extremely critical that your users be able to intuitively use the features of your website with any cultural, design, or knowledge barriers made as low as possible. If they don’t find your product easy to use, then they can turn right back around and go with someone else.
Naturally, though, nobody expects that they’ll immediately know how to use the software for the first time. Your job is to make the process of learning to use it – and solving the problems that arise – intuitive.
That’s where high-quality documentation comes in. When people see your help desk page, they should be able to make an educated guess about where the right information is for their problem, every time.
You need to have a serious search engine that shows your users where the necessary articles are, as well as an easy-to-read hierarchy of article categories that lets them understand that they can get access to related articles in seconds. It also all needs to look just like your website, so that there are no subconscious clues that they’ve found themselves in the wrong place.
And why is it that it’s so necessary to spend time and energy writing effective documentation when you could just get people to answer phone calls and support emails?
Well, it turns out that users love helping themselves more than they love getting told how to fix their problems. You need to let them feed their first impulse to click around on the site and see if there really is a self-service area that can help them, and only once that avenue is exhausted will you point them toward a contact form.
If a user can find the necessary answers on your website, then suddenly your website seems well-designed to them and they’ll be happy to return and use it more frequently in the future.
Plus, as you may have guessed, documentation is a whole lot cheaper than hiring people to answer your phones, even if you outsource it overseas. Even part-time phone support can cost over a thousand US dollars per month, while even the most expensive enterprise-level knowledge base platforms cost less than half of that.
Platforms for You to Build Your Documentation
So far we’ve mentioned knowledge bases a couple of times as platforms you might want to use, but it’s only fair to mention other product documentation software packages that work for some companies as well.
Of course, the simplest and most cost-effective solution for you (apart from having no documentation at all) is to just write up a quick user guide or answer some FAQs and put that on a static page on your site.
This is painless and free to set up, but there are a couple of glaring downsides. First of all, you only get one page to help boost your search rankings. Second, you’ll have to manually update it every time your software changes, which in SaaS could happen quite a bit.
Finally, as soon as you have more than ten or fifteen questions to answer (and most users could come up with ten or fifteen questions about just a login screen), you should really be splitting them up over multiple pages or else your users get distracted.
Then updating the pages becomes even more tedious, and with several help pages on the site the webmaster could get annoyed at the backend organization.
Another way is to use free wiki software, like some companies have done to set up an easily-editable collection of help pages.
As long as you’re comfortable hosting wiki software, this could be a decent solution for people who don’t want to get used to learning how to use another type of dedicated knowledge management platform. After all, most people have used Wikipedia and so have a good sense of what that kind of platform looks like and how it works.
However, the design of most wikis tends to be quite lacking, and it’s immediately obvious that you’re bolting a wiki solution onto your existing website instead of smoothly integrating something natural.
Wikis also tend to have pretty bad search features – take a look at Wikipedia itself to see how its search feature appears to be stuck in the early 2000s. Search is a key component of finding answers quickly, and if your customers get frustrated with your documentation platform, they might be more likely to feel turned off from your product as a whole.
This is why most people use a knowledge base (also called a help desk by some providers) as the foundation of their documentation needs.
A knowledge base is designed from the ground up not to be an all-in-one package like a Wiki is, but to do the specific job of adding and editing help articles – and to do that job well. Many integrate with CRMs or other help desk software features like instant chat or customer issue tracking, while others like Document360 focus entirely on building and maintaining help pages.
There’s not just one perfect solution that can solve every documentation problem you have. However, there are certain key features that you’ll want to keep an eye out for and compare. If you’re considering a particular type of technical documentation software like a knowledge base, make sure it has a strong implementation of these key features.
Just as you want your readers to be able to use your documentation without any trouble, you’ll also want your writers to be able to edit your pages and add new articles as quickly and easily as possible.
You want your page editor to be just like a word processor in its accessibility, but also employing some key features such as Markdown for power editors. This way, for instance, you can add all the necessary formatting you need without having to take your hands off the keyboard and onto the mouse.
Your editor should also have a good ability to add photos, videos and other content. Although your articles should generally be short (more on that later), you should definitely consider adding multimedia to help guide your users along, particularly if your user interface is heavy with text that might be confusing to a non-native speaker of English.
Inside the page editor, you should also be able to perform bulk features like editing and moving articles from one category to another. After all, sometimes you have a product update that requires a big shuffle in the way your articles are ordered – better to do that all at once if you can.
The Search Bar
As strong as those categorizations may be, a search bar is what really makes a knowledge management system shine.
Check and see what happens when you put in a basic keyword, for instance, like “open.” Does it bring up a ton of unrelated articles just because they included that word, or does it intelligently put the most general and basic pages first – since users who search for basic keywords probably aren’t at the expert level?
Also have a look at the results when you type in a purposefully misspelled word. A good search bar will implement a fuzzy search algorithm to make sure you can get the results you’re looking for even if your fingers have slipped on the keyboard.
When it comes to layout, the search bar should be prominently placed so that users see it first. It should look good on mobile and desktop layouts. Speaking of design…
Although knowledge bases have their own design language of sorts (many people make heavy use of emojis, for instance), you want the ability to make your documentation look seamless on the page.
Most SaaS products rely a lot on branding and word-of-mouth to expand to more users. If your knowledge base pages, which bring users to your website and thus to your brand, look like they came from someone else’s website, then you lose the credibility that comes with having a seamless website experience.
You should be able to use whichever knowledge base provider you’d like as a “white label,” meaning that there’s no obtrusive branding poking through. Naturally, this also means customizing the layout and color scheme of your pages to match the rest of your website.
Versioning and Differences
When rapid software prototyping and release schedules are the name of the game, you want your documentation team to be ready at the trigger.
After all, if you push out an update and there’s a problem or new feature that your documentation doesn’t address, you’re going to be looking at confused and frustrated customers at just the wrong time.
Your product documentation software should allow your writer or writers to flip back and forth between the current version of your help docs and any planned changes at a glance.
You should also be able to look at two different versions (such as one saved at 10:00 AM New York time and one saved at 12:30 Beijing time) to look at how two different editors might have tackled the same assignment.
With these features in place, you’ll be able to keep organized, and you won’t have to deal with a Google Docs-like problem of several competing versioning schemes and time zones making your team confused about which versions are current.
Aside from a good user experience, you want to get something out of the deal as well. What can you gain from simply hosting a knowledge base?
You can get data.
Each user leaves a footprint in your logs when they visit or conduct a search, and those footprints can be aggregated over time to make it apparent to you which articles are the most popular, which articles need work and which articles have just the right amount of monthly viewers.
All of this should be available on the back end of your documentation management platform of choice. Ideally, you’ll also be able to look at the search bar usage statistics, such as how many searches you get per unique visitor and how many searches you get in the aggregate.
One particularly useful data point is the list of “dead keywords,” or searches that returned zero article results. If those are misspelled words, fine, but if those are keywords related to your product, then you know you’ve got to step up your article creation and fill in the blanks.
With this data, you can of course improve your documentation, but you can also use it as a general pointer to issues your customers may be having with your product. It’s free user experience testing and response data!
Before we close out here, it’s important to go over three key principles that govern how you should actually structure your articles on the knowledge base.
Your documentation is not a place to show off your writing skill. Good technical writing should be invisible, because it should convey its message precisely without ever causing the reader to notice the style.
This means that your articles should all be pretty short. As a general rule, once you write an initial draft, try to reduce the word count by about ten percent.
Speed-readers and skimmers will thank you for this, as will people reading in their second or third language.
Every article needs to effectively solve a problem or provide concrete steps for getting the user’s problem to a slightly better state.
You’d think that this would be common knowledge, but as it happens there are a lot of people out there writing documentation that’s just thinly veiled advertisement for their products, or cribbed from somewhere else without being thoroughly vetted for effectiveness.
Use clear and direct language to guide the user through what they need to do step-by-step. Some platforms let you put flowcharts or nested instructions into the article so you can tailor the experience to people using your product on various devices.
This might even be the most important principle! You should aim to have your articles be as relevant as possible in terms of how they relate to the actual usage of the software.
Good technical documentation software will let you easily see which of your articles are the oldest and give you reminders to check those out when you can. You should also make it a habit to run audits two or three times per year – more if you have a fast release cycle.
These audits should cover all of your articles in the knowledge base, and they should check for dead links, outdated information, and photos or videos that might refer to an older design of the user interface.
It may seem obsessive to pay so much attention to keeping your documentation up to date, but remember that your clients are paying you monthly with the expectation that you continually develop your software for them. It’s an unwritten part of that deal that you’ll also keep your documents held to the same standard of quality.
When all is said and done, we recommend Document360 for your knowledge base needs. It checks all the boxes mentioned in the features section and does it all with grace and style. It’s even been highly praised on trusted aggregator websites such as Capterra.
You can take a look at their own help desk for inspiration and a great example of how it’s done in terms of organization and writing best practices. And if it seems like something you’d want on your own website, you can get access to the full features for fourteen days with a free trial!
Your customers deserve the best software and the best service. Use a great knowledge base, and you’ll be able to offer them both without compromise.
Also Read: Introductory guide to process documentation