Articles in the series
When it’s time to plan out what articles you want to include in your knowledge base, there’s no need to guess; you should have plenty of existing resources to help you determine what you need to write about. For example, you can look at your existing support requests to find what your customers ask about and have trouble with most often.
This article covers the following topics:
Searching for article ideas
As you’ll see in the article we’ve linked to above, the following are four incredibly helpful questions that you should ask when you set to determine what articles you need to create:
- What are common issues?
- “Users always struggle with X.”
- What are frequently asked questions?
- “Users always ask Y.”
- What are known issues that impact a lot of customers?
- “Your website does not function correctly on mobile devices.”
- What are the most time consuming issues?
- “It takes 30 minutes to set Z up.”
To answer those questions, providing you already have some history supporting your customers and therefore have the data, here are the resources that you should have available to you.
| Existing ticket data |
Your existing tickets have plenty to tell you about what the common support issues and your customer pain points are. You can review your open and resolved tickets for common support issues that you can turn into knowledge base articles. |
| About custom field |
To efficiently categorize and analyze your ticket data, it’s helpful to use custom ticket fields. A commonly used agent-facing custom ticket field is the About field. You create a custom About field (see The 'About' Field) to help you categorize incoming support requests. An About field allows agents to select from a drop-down list the different categories within the products and services you provide (for example, Payment Issue, Returns, Product Defect, and so on). Your list should contain whatever is relevant to your business or organization. After this data has been captured, you can generate reports to analyze and help determine the content you need to create. For example, if you’re receiving a high number of tickets related to making returns, this can indicate that a knowledge base article on that topic should be created to provide the information your customers need. For more information, see Analyzing ticket data to determine customer issues. |
| Resolution custom field |
Similar to the About field, you can add a custom ticket field to capture the support issue resolution. For example, you can create a drop-down list with resolution values such as User Education and Documentation Fix. User Education would indicate that the support agent needed to provide instructions that most likely should be in a knowledge base article. Documentation Fix would indicate that an existing knowledge base article was incorrect and needed to be updated. For more information, see Using the 'Resolution' field. |
| Existing internal documentation |
Review internal documentation for article ideas. For example, your support team might have already created internal documentation for common support issues or product specs are available that you can use to create an article about how to use your product. For more information about using internal documentation to look for content ideas, see Looking at other sources to determine customer issues. |
| Support macros | If your support team is using macros to quickly respond to common support issues, those can be an excellent source of ideas for knowledge base articles (for example, a macro that explains how to request a refund). These sorts of issues that are easily resolved with a standard set of instructions and that apply to all users should be documented in your knowledge base. |
| Frequently used tags |
Ticket tags are also useful in helping you to categorize tickets and find common support issues. Similar to the About field, you can use tags to add more detail to the ticket that can be helpful in drilling down into the specific areas that require support. A common use of ticket tags is to indicate that the issue points out the need for some customer facing documentation. For example, a standard practice is to add a ‘doc-needed’ tag when agents see an issue that requires documentation. |
| One-touch and two-touch tickets |
One-touch and two-touch tickets are a good place to look for content ideas because they often indicate support issues that are easy to resolve and therefore a good fit for self-service. An example of that is something such as ‘how do I reset my password?’. It’s probably not something that a support agent needs to handle; it’s more likely that the customer can do it themselves, but they just aren’t aware of that or can’t find the instructions for how to do it. Support issues like these are usually handled with a single response from a support agent – a one-touch ticket. Using Zendesk Support you can easily locate the support requests that were resolved with one interaction. To see how you can report on one-touch and two-touch tickets in Zendesk Explore, see Explore recipe: One-touch tickets. |
| Google Analytics |
One of the many things that Google Analytics does is track the search terms that your customers use when they visit your website. Google Analytics can and should be enabled for your Help Center (see Google Analytics and Help Center - Part 1: Asking the right questions). If you haven’t launched a Help Center yet, check the search term metrics provided by Google Analytics to see what your customers are looking for at your website. You may find that a number of your customers are looking for information about specific issues (for example, ‘shipping problems’ or ‘can’t sign in’). You can also investigate what search term refinements they’re making – the other words that they are using to try and find the information they’re seeking. See Google Analytics and Help Center - Part 2: Measuring the effectiveness of search. You’ll not only discover some articles that you need to create, but you can also use those search refinements as labels in articles to help ensure that the article is returned in a Help Center search if an alternate search term is used. For example, if you change the name of a product, you can use the old name as a label to help your customers find the articles they need. See Using labels on your Help Center articles. After you launch your Help Center, you can use the Support reporting Search dashboard to review the search terms that your customers are using (see Viewing top content, searches, and agents). |
| Your subject matter experts and community |
The people who deal directly with customers probably have something to share with you about what needs to be documented in your knowledge base. Talk to your support agents and people involved in product development about their ideas. If you have an active user community and a forum for them to provide you with feedback (such as Zendesk Gather), you can either solicit them for feedback or review what they’ve already shared with you via their community posts and comments. You should also review your social media channels. |
Creating the list of articles you need to write
As you’re doing all that research, capture your article ideas and needs in a list somewhere (Google Docs, your internal wiki, etc.). You can also create article stubs directly in Guide and then assign them to writers to complete the articles.
In the next article in this series (Getting started with self-service – Part 4: Writing your knowledge base articles), you’ll find some best practices for creating a plan to get the writing done and getting your knowledge base articles published.
Assigning the writing work
If you’re working with a team of people who are helping to create your knowledge base articles, the first step is to divide up the work and assign specific people to write specific articles.
Based on the research you did to discover the topics you need to cover, you should have compiled a list of articles that need to be written (if you haven’t gotten down to the level of defining specific articles with titles, even a comprehensive list of subject areas is a good place to start).
Whatever level of detail you’ve gotten to, at this point you should know what needs to be written. Share that list with your team and assign specific parts of it to the team members. Who you assign to what parts will probably be determined by who has the subject matter expertise.