How to Create a Content Plan for Your Support Team

Here on the Tettra blog, we’ve recently covered the different types of support documentation and how to create great customer support documentation. 

But writing individual support articles only gets you so far.

First, you need to know where to begin when creating customer support content. 

• What should be documented? 
• What needs documenting? 
• What comes first? 
• How often should pieces be updated? Is any of this content even useful? 

It can be overwhelming. I get it.

A content plan helps alleviate that overwhelm and answer those questions, so that when you get to creating your documentation, you’ll be confident it will do the job you’re hoping for. 

1. Decide what needs to be documented

The first step in creating a great customer support content plan is defining the purpose of your content. 

This  determines what  you need to create and where you might want to start.Always ask: what is the purpose of your content?

If you’re building an external knowledge base, your aim is to educate customers and empower them to help themselves. 

So, you’ll want to document the ins-and-outs of product usage, best practices, and basic troubleshooting, yet avoid the nitty gritty that could create negative customer perceptions or confuse users.

If you’re making an FAQ, figure out the most common questions and provide short, succinct answers that link to more detailed docs.

Or, maybe you’re focusing on an internal knowledge base, like creating a source of truth that helps your support staff find answers quickly, enabling them to meet their response time goals and improve customer satisfaction.

Whether it’s new hires coming aboard or a support member digging through a case for one of those legacy plans, your internal knowledge base should provide all the details needed to give a complete picture of the problem and its solution.

2. Make a list of topics to cover

Once you’re clear on your content’s purpose, you can decide what content needs to be documented. It’s best to start by creating a list of topics to cover. 

This will vary from team to team, so let’s go over a few examples.

Say you’re creating an external knowledge base for your newest customers. 

In this case, you would simulate customer behavior by diving into your platform and noting down every step of the customer journey.

The first thing a customer would do is login. 

So, “how to login” is a potential topic to cover (pro tip: it’s not the best topic, but write it down for now and we’ll circle back on why you don’t want to spend much time on this later in this post). 

Related topics like “how to reset your password” and “how to change your username” can also go on your list. 

Walking through this process as a user leads to the realization that if you’re a first time customer, you’ll actually need to create an account as a first step. Write that down.

Go through your entire platform in this manner, making note of every potential topic you could cover.

You’ll end up with a really long list, so it’s not a bad idea to organize your topics in categories, similar to how you would outline an article. 

But what if you’re creating an internal knowledge base?

Creating an internal knowledge base isn’t as straightforward—you can’t walk through a support agent’s journey in the same way. You’ll need to approach a content plan for your internal knowledge base in a different way. 

First, pick a topic or question that you know customers will ask about. Looking at historical support tickets is a great place to start. Then, set a timer for ten minutes, and write down everything related to this topic that could be documented for your business. 

Don’t overthink it. Just write a stream-of-consciousness list. Whatever comes to mind. 

As an example, we’ll use a topic that relates to every business: refund requests. 

Whether you provide refunds or not, your support team will still get asked for them, so you’ll want to have a good answer. 

I gave myself 45-seconds and wrote down everything I could within that time frame.

This is what I came up with:

• Are refunds issued?
  • If so, what are the circumstances?
• Do I need approval to give one?
  • If so, are there circumstances where I don’t?
• If approved, who issues the refund?
  • If I issue the refund, how do I go about doing it?
    • What system do I use and how do I use it?
  • If someone else issues the refund, how do I communicate with them about this?
    • Do I reply to the customer first or do I leave it for the refunder to handle?

As you can see, you’ll quickly get in the weeds. Write down everything that comes to mind during this brainstorming step. You can decide later if it deserves documentation or not.

After you’ve done this, ask your team for feedback. You can have them complete this activity themselves, or use a tool like Tettra’s Q&A feature to capture your team’s questions over time. 

It eliminates the need to dig deep into past tickets, emails, Slack, and other tools to find every possible topic you should cover in your internal knowledge base, and it routes new questions to the right subject matter experts to provide accurate answers.

Finally, start thinking about what doesn’t exist yet. What features are currently under development? What’s on the roadmap for next year? Two years? 

While roadmaps always change over time, capture whatever you can on your list for now, because it will help with the next step

3. Organize your topics

Now you’ll create an organizational structure that works for both the content you’re making now and content you’ll need in the future.

The goal is to group topics into some sort of logical order. A good rule of thumb is to aim for no more than eight to ten top-level categories. 

If you’re building a single product knowledge base, you really only need one category level. If you have multiple products, each product should be the top-level category, with subcategories for each product.

When building an internal knowledge base, subcategories are fine, just aim for no more than eight to ten at any given level.

Apple does this exceptionally well. Its knowledge base is grouped by product (seven of them) with two additional categories for the topics that relate to all of its products (billing and repair). Apple also includes a “forgot password” section at the forefront of its webpage — a huge signal that this is likely the number one issue people visit the support center to resolve.

Source

Begin by grouping items into single pieces of content, and then arrange those documents into categories. It’s often easier to start organizing with the more detailed stuff, then group it together into overarching categories.  

Let’s say you’re organizing that internal documentation about refunds from earlier.

If we go through the list of questions, you’ll begin to see a few different article outlines forming:

1. How to handle a refund request
   1. Refund policy
   2. Evaluate request circumstances
      1. Does the request fall within the policy?
   3. If a refund is to be issued
      1. How to reply to the customer
      2. How to logistically issue the refund or get approval (provide a link to the article)
   4. If the refund is to be denied
      1. How to reply to the customer
2. Getting approval for a refund
   1. How to get approval
   2. What information to include for the approval
   3. Who replies to the customer
3. How to issue a refund
   1. What system to use
   2. How to issue a full refund
   3. How to issue a partial refund

The common theme of these articles is refunds. A “Refund” category might work, but if it’s just these three articles, it’s better as a subcategory.

To figure out what category your refunds subcategory should live under, zoom out a bit. What else fits here? Invoicing and refunds have a lot in common. 

So maybe you could make a “Billing” category that encompasses both.

Keep going until you have a master list of categories, subcategories, and articles. Toss oddities into a “Miscellaneous” group for now; the right spot will likely reveal itself as you go.

Pro-tip: Crowd-source your team for opinions. Your logic might not click for others. Collaborate until you find a structure that’s as intuitive as possible.

Using Tettra makes this process easy. In the past, I used digital whiteboard systems to create cards for each article and moved them around within different groups until I found the best fit. 

Tettra’s knowledge base software does this right within the system.  Create your categories and subcategories, then move things around or rename them until you find that perfect fit. 

Learn more about categories in Tettra. 

4. Decide how to prioritize

As you organize, it will usually become apparent what needs to be written first (and what is a lower priority). What questions are the support team seeing the most? 

If refunds and billing take up a ton of time, that’s where you start.

This is another place where Tettra can help. Your team can upvote questions  that they want answers to first.

Pro-tip: Do you have new product releases on the horizon? High-priority alert! Document it before the grand reveal. Preempt the team’s questions with spot-on documentation so you’re not bombarded later on and so that your customers have a great support experience right off the bat.

5. Start creating content

The majority of your content planning should be done at this point, but as you outline and write, you’ll continue to refine the organization of your content list. 

Outline your articles

You should already have rough outlines of each piece as a side effect of creating your topic list, but now is the time to further build out those outlines.

Take How to handle a refund request from our list of refund articles. 

We already have a rough outline, we just need to go through and pad it out based on our particular circumstances.

Start outlining all articles in a category or subcategory before diving into the actual writing. Why? It helps you realize when a full article might not be necessary for a topic, saving you time in the long run.

Here’s the litmus test for whether an article is needed: if you can’t create at least three logical headers for that topic, it probably doesn’t deserve to be its own article. Consider blending the information into a broader piece.

Let’s circle all the way back to the beginning. Remember that first topic idea we had for a customer-facing knowledge base about how to login? 

That’s a pretty cut and dry topic and shouldn’t need a detailed article. If users are actually struggling here, you might need an article in the short-term, but the real solution is to work with your product and engineering teams to improve your platform’s login procedure. A better product is always better than documenting a faulty process. 

Create articles

You’ve created your plan, and you’re now ready to create your documentation itself. We’ve covered this in detail in How to Create Support Documentation for Both Your Customers and Your Team. Check that out for an in-depth step-by-step on how to actually create great support documentation.

Although I do have one gem to point out related to creating your documentation: because of your content planning process you have a solid list of topics (and maybe even outlines, like in the refund example we discussed). 

As you flesh those out, remember that much of the content you need to create likely already exists—it’s in your support tickets, Slack channels, and email threads with other internal teams. 

Don’t start from scratch unless it’s necessary. Use those resources to speed up your documentation process!

6. Analyze, review, and revise

Your content plan is crafted, your articles are penned, and your little support machine is chugging along. You’re all done, right?

Nope. Not even close.

The biggest mistake people make when creating documentation is believing that once an article is written and pushed out into the world, that it’s done and over with. But knowledge bases are living documents. They grow and change with your company.

When a product or feature shifts, the document needs a facelift—new words and fresh screenshots.

Likewise, if an article is underperforming or is generating a lot of questions, you’ll want to rework it. After a piece of content is published, keep a close eye on it for a few weeks. 

Check your analytics often and quickly make adjustments if you notice something amiss.

Once you see positive returns from your content, continue to check on each piece at least quarterly to ensure screenshots and language are still in line with your current products and policies. And of course, if something ever changes, update the documentation to reflect this.

Content crafting excellence with an internal knowledge base like Tettra

Crafting a content plan for your support team is an ongoing commitment to excellence and customer satisfaction. It takes work, but it pays off in happier customers a more effective support team, and more scalable customer experience.

Start with a clear purpose, organize your topics effectively, prioritize based on impact, and engage your team throughout the process.

To make the work easier, use tools like Tettra to streamline documentation and keep your content dynamic.

With Tettra, you’ll get:

1. Seamless Integration with Tools You Already Use: Tettra stands out by offering robust integrations with popular workplace tools such as Slack, Microsoft Teams, Google Drive, GitHub, and Zapier. This seamless integration makes it incredibly easy for teams to access and share knowledge without leaving their daily workflow, enhancing productivity and ensuring that important information is always at hand.
2. AI-Powered Knowledge Management: Leveraging AI, Tettra provides an advanced knowledge base that not only stores information but also helps in curating content to answer repetitive questions directly in Slack. Its AI capabilities ensure that the knowledge base is continually up-to-date, organized, and complete, reducing the time spent searching for information and increasing efficiency.
3. User-Friendly Interface and Easy Setup: Designed with a focus on modernity and ease of use, Tettra offers a simple, intuitive user interface that makes it easy for teams to get started and stay engaged. Its straightforward setup process, especially when compared to alternatives like Guru, means that you can quickly implement Tettra within your organization without a steep learning curve.
4. Comprehensive Knowledge Sharing and Verification Tools: Tettra emphasizes the importance of keeping knowledge accurate and current. Features like the Q&A workflow, content verification, and the designation of “knowledge experts” ensure that your knowledge base remains a reliable source of information. These tools empower teams to capture questions, document answers, and verify content efficiently, fostering a culture of knowledge sharing and collaboration.

Sign up for a free Tettra account, and get started with your company’s internal knowledge base today.

---

Anne-Marie works as a Fractional Head of Customer Success focused on 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.