Last updated on Feb 11, 2021
Documentation is the most rock n’ roll part of a SaaS company, right? Probably not.
Documentation for your SaaS product is crucial, though it may not have been high on your list in the whirlwind that is in a SaaS startup.
It is more than just a cost-saver for Customer Support. You may already have made some stabs at publishing some documentation, but it’s time to take your documents to the next level.
Since SaaS companies operate on a subscription model, you regularly interact with your customers. This means you are uniquely positioned to benefit from documentation.
Having solid SaaS product documentation directly contributes towards building a strong, ongoing relationship with your customers and therefore reduces churn.
Churn is one of biggest barrier to your growth, so SaaS companies cannot ignore the need to have good documentation.
Right now, you could be sitting on an opportunity to make your customers happier. You can reduce customer support requests with reactive documentation – docs created in response to issues your customers are having.
For SaaS businesses that need to scale, product documentation is essential for keeping your number of tickets per customer as low as possible. You can make your product more user-friendly with documentation to reduce churn.
SaaS product docs also have the potential to help your startup improve onboarding. This is possible with proactive documentation.
Did you know that documentation can also help you with increasing your online visibility? Yes! The advantage of having killer documentation is that it can be part of your content marketing strategy, especially if your SaaS product is related to a popular industry.
Ultimately, it can and should be included in your efforts to optimize your knowledge base using SEO.
For example, MailChimp’s knowledge base matches queries relating to email marketing. If you search ‘analyse email subscribers’, their documentation shows up in the search results. This is a great way for potential customers to discover their product.
This approach works best if your knowledge base is a sub-domain of your main website, and counts towards your site ranking.
To actually create proper documentation for your SaaS users, you need to focus on nine key areas.
We’ll go into detail on how you can create killer SaaS product documentation for your users now.
You can’t create killer documentation if you don’t know exactly who you’re writing it for.
Your documentation may be either aimed at end users, internal staff, API developers, or a combination of these audiences.
It’s critically important to clearly define the target audience for your knowledge base. If necessary, you should divide the content into separate knowledge bases. It’s all about as being specific as possible.
Before you invest time and resources on a killer knowledge base for your SaaS, conduct in-depth interviews and surveys. Find out exactly who your customers are.
Even a few emails asking for feedback from those people who contact your support team is better than nothing.
Wave knows exactly who its knowledge base audience is – small business owners
Did you know there are different types of technical documentation? You’ll need to be clear about which one you’re creating.
Types of SaaS product documentation can include:
Being clear about the type of documentation means it can be optimally formatted and presented to your users. You must keep distinct types of content apart to avoid confusion.
Tutorials are for practical learning and contain little to no reference material. They’re quick and dirty guides for beginner users to get acquainted with the basic features of your software.
These are more advanced than tutorials. How-to-guides walk users through the process of completing a specific task, and one that beginners probably couldn’t formulate. This could include how to troubleshoot if your program crashes.
Explanations are discussions of concepts. They are theoretical rather than practical. The aim is to get your user to understand something abstract, such as the context surrounding your software.
Reference docs are technical descriptions of your software. These might be more common in developer docs than for end users of your software. It’s possible that they could still be useful for end users in case potential customers show your docs to their in-house developers.
SaaS product documentation isn’t just a matter of creating a load of content and throwing it at your customers.
The layout and Information Architecture of your knowledge base has to be carefully designed. This will assist in the learning process.
Information Architecture (IA) provides signposts to your users, showing them the way around your knowledge base. It’s affected by things like consistency in naming conventions, hierarchies, and categories. It shows your users potential use cases for your software and improves ROI on your product.
IA also tackles the unconscious incompetence, and the conscious incompetence, of your users.
Unconscious incompetence is when your users aren’t aware of what they don’t know. User onboarding documentation helps educate your users out of this state. But what about the rest of the time?
Conscious incompetence is when your users are already aware of what they don’t know and have a problem with your software. The job of your docs is to provide them with appropriate content that smoothly fixes their problems.
SaaS product documentation is not going to be consumed in a linear fashion like a book. Users will be arriving at your knowledge base from different places.
In the old days of printed technical user manuals, each edition of the manual had to be reprinted every time a new version of the technology came out. It was written in a style intended for users being able to read from A to B, or use the table of contents.
This trend has carried over into the documentation field. But modern browsing habits mean that your customers will be coming to your documentation from different sources. Each piece of content has to make sense as a stand-alone potential landing page.
The key is to make your content skimmable by chunking it. Treat each piece of content as a recyclable ‘chunk’ of information.
Make sure to have no more than one essential topic covered in each piece and link related content topics together. Use menus and navigation to help users get to other topics.
Think of your content as being part of a cloud, rather than a sequence.
Quality is a subjective state but there are some criteria you can use to evaluate whether you’re producing quality documentation or not.
You can’t take a scattergun approach to your documentation because this will erode trust. If one of your key features is not documented or the documentation is out-of-date, this is arguably worse than having no documentation at all.
Your documentation has to be a complete library of everything your users would want to know about your product. This doesn’t mean you include every single article on your knowledge base homepage, but all the information should be available somewhere.
At the same time, everything you include must be highly relevant. This is no time to be precious or wordy with your content.
Get to the point quickly and cut out any superfluous information. If you planned to go back and read over your documentation for the purpose of editing and you find yourself getting bored. This will bring a big red flag that there is too much information in your docs.
Use only the precise number of words you need to get your point across. Put the solution to whatever problem you’re addressing near the beginning of your content. Then elaborate for those users who step by step through the process.
End users of your product will be relying on you to supply all of the necessary context for your documentation. This means no guesswork – users must understand immediately whether they have found the right content or not.
You can supply context by briefly explaining how much users should know before they can benefit from your article. Mozilla does this really well in their developer docs:
Simple is not the same as dumbed-down. When your documentation is simple this means you decided to show the basic information at any given time.
Only a small number of your product’s features used by your customers so check your analytics to see what documentation is most needed. Use this to determine a pathway to send your users on when they arrive at your product knowledge base.
Stripe keeps it really simple:
Quality documentation ultimately rests on knowing your audience, how they learn best and how you can fulfill their expectations. There is no magic formula because every audience is different.
Follow these tried and tested principles to maximize your chances of success, and hire professional technical writers to help you achieve this goal.
Some companies are a fan of agile methodologies and follow a docs-like-code approach to documentation. While this can be a fantastically useful approach, SaaS product documentation follows a slightly different process to code documentation.
Product docs should be updated as frequently as necessary – when errors are found or when new content is produced. It doesn’t necessarily align with your development cycles and how often you like to ship code. Additionally, it may not be very realistic to expect your technical writers or support agents to learn to use developer tools like Github in order to publish docs.
Sometimes the end user of your software is a developer, but this still doesn’t make product documentation the same as code documentation. Code documentation is specifically about the code and is usually aimed at improving communication between internal developers anyway. Product documentation targeted to audiences outside your company.
Different teams and team members should be responsible for delivering different types of documentation – even if they are all producing ‘documentation’. Evaluation should happen at different levels to measure the success, so don’t force everyone to use the same tools or processes.
If you’re selling a SaaS product, you’ll usually be in need of an online knowledge base to house your help content. Knowledge base software solutions are abundant but few of them designed specifically for SaaS documentation.
Technical authoring tools like Madcap Flare are intended for large-scale businesses producing documentation in many different formats, over print and web. These are too weighty and inappropriate for your average SaaS company.
Other knowledge base solutions aimed at enterprises and come with a price tag to match. SaaS startups need software that scales at a price point which feels comfortable on a more modest budget.
And because you may already have a help desk solution you’re happy with, you probably don’t want a knowledge base bundled in with support software. You just want a simple knowledge base.
Since you deliver subscription software over the web, you need a tool that works in the same way. You need a SaaS knowledge base solution.
Our own product Document360 is knowledge base software aimed at SaaS companies and you can sign up for a free trial.
Sometimes producers of documentation like to spice up their content with different formats such as:
Often an image really is worth a thousand words and can improve the user’s learning experience.
Remember though – videos and screencasts can be trickier to update than written documentation, and you may have issues when it comes to internationalization.
Videos and images are also not accessible for users of screen readers, so you should always provide a written version to accompany your visuals. This can end up being a lot of extra work.
That’s not to say that you shouldn’t use videos as they can be an incredible way to convey information about your product. Just be aware of maintenance and accessibility issues.
Your SaaS product documentation is never finished. It’s always evolving, just as your product evolves.
Most SaaS companies are open to the fact that customer service takes place primarily online, and so that’s where their knowledge base should be. The nature of software development means they’re familiar with the concept of continuous iteration. In fact – their businesses are founded upon it.
This has led to some documentarians following a docs-like-code approach (as we mentioned earlier). This means borrowing from the principles of software engineering and keeping your docs in the same repository as your code.
Whether or not this will be appropriate for your startup must be decided on a case-by-case basis. You must, however, keep your docs completely up-to-date with the latest version of your product.
At no point should customers be able to access docs that aren’t completely accurate. This risks damaging your product’s reputation and destroying your credibility.
Some people think a good product should just document itself. That means the product is so user-friendly that no documentation needed at all. This approach implies that, if your product needs documentation, you’ve failed at User Experience.
In reality, most software products have sufficient complexity that not every function is immediately obvious. Not every use case for your software is always intuitive. This is where killer SaaS product documentation software can come in really handy.
The importance of docs all comes back to the idea of unconscious incompetence, or your customers being unaware of what they don’t know.
SaaS product documentation is your silent partner in reducing churn and increasing customer happiness. Bet you can’t wait to start now!
Look at the top search terms in your knowledge base if you have one. If you don’t, interview some of your customers about their biggest problems with your software. Then, create a plan for your knowledge base content and structure your SaaS product documentation around that plan.
Publish your content and continuously improve your knowledge base, building new processes to ensure success.
Using a knowledge base software can make this entire process extremely more efficient.
Your documentation needs a tailor-made house to live in. Think about investing in kick-ass standalone knowledge base software like Document360Start your Free Trial