The 6 Major Types of Support Team Documentation You Definitely Need

Anne Marie Traas
Anne Marie Traas
December 14, 2023

Support teams are constantly dealing with change. They’re forced to think on their feet, adjust on the fly, and have to be masters of finding accurate answers quickly. 

That’s why having great support team documentation matters so much. Documentation is an essential element in the toolbox of your customer support and customer success teams. 

It’s the critical foundation for providing effective and efficient support to users. It makes training new team members far easier. And it ensures that your support team’s can deliver a consistently excellent customer experience.

What is support team documentation?

Support team documentation encompasses a wide range of resources that help your customer support team do their jobs effectively. These resources play a crucial role in helping your team understand the intricacies of your product and your processes so that they can efficiently solve customer issues. 

The core objective of creating support team documentation is to standardize your approach to handling customer inquiries. Documentation becomes your source of truth — it provides clear guidance and training to team members, equipping them to do their best work. 

And while you may have customer-facing documentation in your help center, your support team documentation is primarily intended for internal use. It usually lives in an internal knowledge base tool that makes it easier for team members to search and find answers on the fly. 

The benefits of well-structured and regularly updated support documentation are significant:

Good documentation empowers your team 

Documented processes serve as a reliable reference, giving every  team member access to the same information. Rather than escalating issues or waiting on a senior agent’s help, frontline team members can tackle customer issues themselves. 

Thorough documentation is particularly beneficial in complex scenarios where specific product knowledge is crucial. By maintaining a consistent source of information, teams can provide uniform

responses to customer questions, which fosters a sense of confidence across your customer base.

Good documentation improves the product experience

Continuously updated documentation reflects the evolving nature of your product. 

By diligently documenting new features, updates, and resolved issues, your support team can identify trends and recurring challenges faced by users. That means this ongoing process of documentation review and revision not only keeps the material current — it also provides valuable insights for product development teams. 

These insights can be used to refine the product, address common user pain points, and make things easier for your customers. 

Good documentation makes training easier

It’s no secret that many support teams see fairly high turnover. Whether it’s due to folks getting promoted or because of people leaving the company, many support managers feel the pain of constantly needing to hire and train new team members.  

Great support documentation makes this way easier. 

When you have your team’s core processes clearly captured in an internal knowledge base, you’re not starting from scratch with each new hire. You’re able to build out a repeatable onboarding  process, part of which can include self-serve training where new agents refer to your documentation.

And if your knowledge base also includes an internal Q&A solution, it’s also super easy for new hires to ask questions and get quick answers from your more experienced team members. 

The major types of support team documentation

Good support documentation comes in many different shapes and sizes (kind of like a box of chocolates). There isn’t a right or wrong format to use for your documentation, although you’ll find that some are usually a better fit for conveying different types of information. 

1. User manuals

User manuals are comprehensive guides that provide a complete overview of your product or service. They’re designed to be the go-to resource for users looking to understand the full scope of what your product offers. 

A well-structured user manual introduces the product and walks the user through features and basic setup. More than just discussing functionality, a user manual provides a bit of value-add — the reason to use a specific feature — as well as basic instructions about how to set up a feature.

What they’re best for: User manuals are most beneficial for new users in need of a thorough understanding of your product’s functionality. 

This format can actually work well for both internal support documentation and for helping new customers (win win!). They help your support team members understand how your product is intended to work — making it easier to identify when something is broken. And they’re great for linking out to from your customer onboarding emails. 

How to do this well: When you man a booth at a conference, attendees who are intrigued by your product will ask you, “What does your product do?” followed by, “How does it work?” You’re going to lose interest quickly if you dive too deep.

Instead, you give them a quick, two or three minute answer — usually accompanied by visuals. Your user manual is that answer, but written down and accompanied by screenshots or a video.

What to avoid: This isn’t the place to do a deep dive into every feature. Instead, speak at a relatively high level and include links to more specific documentation for each feature.

Example: TestGorilla does this particularly well. One of the first articles they share with new users is a getting started article.It provides an overview of how to use their product in less than five minutes. Notice all the hyperlinks sending the reader to more detailed instructions if they’re needed.

Source

2. How-to guides

How-to guides provide step-by-step instructions that help users or agents accomplish specific tasks. 

Each guide focuses on a particular process. Because they’re broken down into bite-size pieces, they make complex processes accessible and  easy-to-follow. They’re a great training resource.

How-to guides should make up the core of your internal knowledge base. These are the resources your team will reference time and time again. 

What they’re best for: How-to guides are particularly useful for navigating team members through the intricate steps of a specific process or troubleshooting common issues. Your team will rely on them. You can also include them as supplemental information in support emails or customer-facing help articles.

How to do this well: People write literal books (myself included) on how to best write a how-to guide, but the core of doing this well is pretty simple:

  • Use paragraphs for non-instructional parts of the guide.
  • Use bullets/numbers for each step in a series of instructions.
  • Give one — and only one — clear action per step.
  • Limit every set of instructions to no more than 10 steps. If you need more than 10 steps, break the guide into more sections.
  • Include relevant yet not directly related pieces of information in visual callouts
  • Add a video walkthrough and/or animated gifs to further illustrate the steps for more visual learners

What to avoid: While you want to help users or team members troubleshoot common issues, you want to avoid over-explaining or drawing attention to things that aren’t relevant to solving a specific problem. 

Here’s an example: 

Your customer sends in an email explaining an issue they’re having with your app. You test the system, even assuming their account to do so, and you’re not having any issues. The most common way to handle this is to ask the customer if they cleared their cookies and cache, explaining how to go about this in the event that they haven’t done this.

Your how-to guide for how to clear cache should definitely outline:

  • Why the agent should request cookies and cache to be cleared
  • General step-by-step instructions for how to clear cookies and cache
  • Follow-up questions in case clearing cache and cookies doesn’t help, linking to the guides on how to use the answers to those questions

It could also possibly outline:

  • Specific instructions for how to clear cache in Chrome, Firefox, Safari, and any other browsers that you know have high usage for your app

It should not include:

  • Steps to clear cache for outdated, unsupported, or very rarely used browsers (think Internet Explorer)
  • How to process the information from the follow up questions that might need to be asked

Example of this done right: Callingly does this exceptionally well. In the example below, notice how setting up an integration requires more than 10 steps. 

To avoid overwhelming the reader, the article is broken down into more digestible sections. Their use of blue callouts for helpful tips ensures these details stand out from the rest of the text. This article ends with a helpful walkthrough video to provide further clarity.

Source

3. Release Notes

Release notes are critical for keeping team members informed about the latest updates to your product. They typically include information about new features, improvements, bug fixes, and sometimes, the status of known issues. Effective release notes are clear, concise, and structured in a way that highlights the most important information first.

Some companies publish detailed release notes for customers — others keep these as an internal resource for teams that work closely with your product.

The complexity of your release notes depends upon the complexity of your product. For a fairly simple product with only a few changes each month, you can keep your notes in a knowledge base article that’s updated monthly. Put the newest release at the top of the article. If you do this, I recommend having a different article for each year, so that no one article becomes too long.

For a more complex product, you likely need an article for each release, allowing you to share more detailed information about each aspect of the product that has been added or changed.

What they’re best for: Release notes serve as a historical record of your product’s evolution. They help manage user expectations about the product’s capabilities and limitations. They also help your support team pinpoint exactly when a feature was changed or released. 

How to do this well: Be concise while fully explaining what was added or changed. Add links to full articles, or article sections, about each feature, so that the reader can easily find and read the updated content within your knowledge base.

What to avoid: Like with user manuals, this isn’t the place to delve too deeply into how to make use of new features or why the changes were made. Simply state each change and move on to the next one.

Example of this done right: Hootsuite has found a good balance between details and brevity. They give one or two sentences summarizing each change, with a link to more information.

Source

4. Technical documentation

Technical documents dive deep into the technical aspects of your product, often catering to a more technically savvy audience. 

These documents might cover API documentation or detailed technical troubleshooting guides. They are essential for users who require a deeper understanding of your product’s technical workings. 

Your frontline support agents may not use technical documentation too frequently, but if you have a tier 2 team or a support engineering team, your technical documents will be their best friends. 

What they’re best for: Technical documents are ideal for addressing the needs of advanced users, developers, or IT professionals who interact with your product at a deeper level. They provide the detailed information necessary for customizing or integrating your product.

How to do this well: Use a tool that allows for technical documentation. These tools provide the ability to add inline code blocks with the rest of your text, allowing for more clarity and easier copying of code.

What to avoid: Be careful that this document isn’t too technical, but be sure it’s written by someone who genuinely understands the process. Ideally, have someone from your development team who is capable of explaining the API collaborate with a great writer from your customer team who can also understand technical details. 

Pairing up in this way enables you to create documentation that’s helpful and understandable to your least technical customers and team members, making it speak to the broadest audience.

Example of this done right: Dimensions’ documentation of their query language (DSL) is a prime example. 

It’s worded simply enough that anyone with basic knowledge of coding languages can understand, while still outlining using the language for complex concepts. It’s written in an easily digestible format, making use of code blocks for quick string copying.

Source

5. Process documentation

Your process documentation outlines the internal procedures, protocols, and best practices within your support team. These are blueprints for how your team operates. Each document details the protocols for handling a specific task, such as answering certain types of customer requests, escalation procedures, or the logistics of handling a ticket.

Process documents can include a wide range of formats including flowcharts, standard operating procedures, how-to guides, and checklists. They might even include some video tutorials.

The complexity of your process documentation depends on the intricacies of your team’s operations. The smaller the team, the less documentation you’re likely to need, while larger teams, with more complex — and more solidified — processes will need detailed guides for every scenario, from solving complex billing issues, to ticket handling logistics, to when and how to push a case through an escalation path. 

What they’re best for: Process documentation empowers your team to find answers to questions about their everyday responsibilities, without the need to come to you directly. Whether a new hire or a veteran, everyone forgets things from time to time. Process documentation serves as an internal how-to guide to standardize the activities performed by each team member.

How to do this well: The key to effective process documentation is clarity and thoroughness. Ensure that your documents are easy to follow and cover a wide range of scenarios that your team might encounter. Include flow charts or diagrams where necessary to illustrate complex processes. Regularly update these documents to reflect any changes in your team’s procedures or the product itself.

What to avoid: Avoid overly technical jargon or convoluted explanations that might confuse team members. The goal is to make these documents as accessible and straightforward as possible.

Example of this done right: Lucidchart provides a great example of a process map that can be used within your process documentation. It’s simple, but it shows what it looks like to break a process down into distinct steps (and it’s surprisingly easy to gloss over steps when creating process documentation). These maps are basic flowcharts, helping you to navigate through the high level steps of an if/then process.

Source

6. Source of truth documentation

Many companies experiment with their pricing plans in the early years of their company. 

This leaves your support staff trying to navigate a variety of legacy customers who’ve been using the product for longer than the team members have been with the company. As a result, the first support hire often becomes the all knowing source of truth for the company’s history.

That’s a problem for numerous reasons, just two of which are that it becomes very time-consuming for one person to be the keeper of all that information (usually in their head). But also, what happens when or if that person leaves?

Ideally, your source of truth should be a centralized, authoritative repository for all your documentation. Not just for your support team, but your entire company. This is where you store accurate, complete, and comprehensive information about your product, service, and protocols.

This should include historical data as well as current information. A known issue where the English version of your product bugs out due to some German specific code belongs here, in the source of truth, but not in the public facing how-to guide. All the information for historical pricing? That’s right — check the source of truth.

The source of truth is basically an internal knowledge base. It enables your customer support team to figure out the semantics of a specific pricing plan that was phased out in 2010, while also providing a new marketing hire with the logistics for adding a blog article to the website. 

What they’re best for: A source of truth is best for, well, everything and everyone inside your company. It can provide onboarding materials for new hires, refresh a new mom on the logistics of her job when she returns from maternity leave, or even allow your entire company to help work in the support queue in the event of a massive ticket backlog (or if you practice whole company support).

How to do this well: Use an AI-powered internal knowledge base tool like Tettra. It’s more intuitive and user-friendly than Confluence, and it’s far more searchable than Google Drive and Slack. It’s how companies like Techstars centralize knowledge management and scale their organizations

What to avoid: Don’t let your content become fragmented or outdated. Inconsistencies in information across different documents can lead to confusion and diminish trust in your source of truth. 

Example of this done right: Tettra’s AI-powered knowledge management enables you to write full-length documentation about specific policies, processes, and more. Then when a team member has a question, they can ask Kai — Tettra’s Knowledge AI. Kai reads through the existing documentation to provide potential answers. If Kai can’t find an answer, it will assign the question to the correct stakeholder for an answer to be provided.

It’s a source of truth with built-in safeguards to ensure it never goes stale. 

Documentation levels up your whole support team (and company)

Effective support team documentation, from user manuals to the process documentation, is vital for the success of any customer team. Each resource in your internal knowledge base is a tool in your toolbelt, enabling your support team to serve customers quickly and effectively. 

Proper documentation isn’t just informative — it’s a key factor in achieving customer satisfaction and operational excellence. To streamline your support team’s documentation process and ensure accessibility as well as consistency, consider taking Tettra for a free test drive today. 

Schedule your demo or start your free trial today. 


Anne-Marie Traas works as a Fractional Head of Customer Success focused providing an optimal customer experience in every interaction. She specializes in driving process & product improvements, creating thorough and easy-to-understand product documentation, and teaching others how to communicate more effectively through the written word. You can find her on LinkedIn.