Knowledge Base Content Maintenance

You’ve invested in a knowledge management program, maybe Knowledge Centered Support (KCS), to improve the availability of self-support content for your customers. It’s going reasonably well, but one day you realize that the amount of written content has begun to pile up. Before you reach this point, I highly encourage you to start a content maintenance program as part of your overall content governance. If you're past this point, well, better late than never.

Why do you need a maintenance program?

You may think of content governance as defining roles and ownership for creating content with appropriate processes and editorial guidelines, which it is, but you need to include ongoing maintenance, too. Without a maintenance program, you likely have one or more of these issues going on.

  • Your support agents and customers are running into irrelevant articles, having to skip listings in search results and/or even clicking and reading those articles that are no longer relevant. Worse, if they don’t realize the article is out-of-date, they might be trying to perform steps or taking action based on inaccurate information. 
  • You are backing up content that you don’t need to.
  • Your search engine is indexing content that is no longer relevant. If you have enough outdated content it may even be slowing down the indexing process.

Think of content maintenance like maintenance for your car. Without appropriate maintenance, you'll start to incur some hidden costs like a decrease in gas mileage. Without a maintenance program, you get less mileage from your help content. If you ignore your car maintenance long enough, your costs can skyrocket from major repairs to a shortened life.

Maintenance Program

I’ve heard of companies auditing all of their content, and that’s entirely possible, but it seems like a very daunting task. (Unless you have a small repository and enough resources, a full audit may never be achievable.) Your content maintenance program should be a part of your content business and never a case of competing for priority. I prefer having some specific triggers that make up my maintenance program and the program being just another part of my knowledge management operation.

Your maintenance program should be ongoing and again, just another part of my knowledge management operation. Don’t let it pile up because something else is more important. If you’re using Scrum methodology, you can easily add new stories whenever there’s a maintenance trigger event. If you’re not using Scrum, you need to make sure the maintenance work still gets prioritized with your other content work.

I’ve made a few assumptions about your knowledge management program. Keep in mind you may need to make some accommodations if these are not safe assumptions for your environment.

  1. Your help content is NOT being used for source-of-truth for product prices, event dates, etc. If you’re doing this, you will always need to manage against a list of articles that require special handling, even if those articles are rarely or never viewed (though you may still want to include them on a review cycle for relevancy). That being said, I highly encourage you to NOT include this type of information in your help content and come up with a more appropriate solution. For example, if you want to promote an event on the help site, use an ad module that is configured to display upcoming events.
  2. Your knowledge base does NOT contain legal and privacy documents. If it does, it likely should be locked down tight with a strict change control methodology. (Occasionally you may need to reference something legal in nature in your help knowledge base. That’s fine, don’t repeat any of it, just link to those documents when necessary.)
  3. You DO have an existing content governance program and a content QA program. Each of these is important for a maintenance program, and I would recommend getting them on track before starting your maintenance program. The governance will help with article consistency, so you don’t have a lot of maintenance due to a difference of opinion from the originally authored content and what is being reviewed for maintenance. The QA program will also help with the consistency between writers as well as it will reduce the maintenance load because you will have less ‘broken’ content to fix.

Maintenance Program Triggers

As previously mentioned, a content maintenance program isn’t just one thing, but rather a series of events and triggers that cause a maintenance review for the content that fits within the trigger criteria.

  1. Update to an existing product or service. Whenever you have an update where the features, functions, or operations are impacted, at least a subset of your content for that product or service will require review for accuracy and relevancy based on the changes -- this is a trigger for review. This review should use the same critical eye as any maintenance review. Whether updates are made or not, the article record should be updated to indicate that a maintenance review was performed.
  2. When a support agent or customer notifies you of an issue. You should have a process defined for agents to report issues that are technical in nature, misspellings, broken links, and missing information. You should do more than just fix the noted error -- use this trigger to perform a maintenance review. If you didn’t recognize it, this is the “Improve Knowledge” step of the Solve Loop in the KCS methodology.
  3. Review based on the lack of article views, over the last 3 (or 4) months. This is just a simple report that you should look at monthly, evaluating page views for all of your content in the last 3 (or 4)  months. Based on normal view behavior, your threshold will vary, but low to no views should trigger a maintenance review for those articles. Your first step with these articles is to determine why they're no longer being view (or perhaps they never have been viewed). Either you’re going to try and make changes (title and SEO improvements) so they are viewed, merge them into other articles, or remove them altogether.
  4. Review based on a high number of views, over the last 3 (or 4) months. Be sure to also look at this monthly. The most obvious action is to make sure your most visited articles are accurate and up-to-date. Because of the high view rate, these topics are important to your customers. Start with verifying the content matches the title. The article I wrote on “Measure the success of your help knowledge base content” (also posted on LinkedIn) can help you figure out whether your articles are effective -- remember, a high view rate doesn’t mean the content is effective.
  5. Updates from 3rd parties such as an OS or web browser. If you’re not paying attention, out-of-date content due to changes from 3rd parties can be a real headache. Nothing is worse than a scramble to fix a bunch of articles because you hadn’t planned for the impact from an OS or browser update. Hopefully, you have the appropriate metadata on your content, so it’s easy to identify those articles that may be impacted by a change to an OS or web browser.
  6. AFTER new content was released (based on a new or updated product or service.) The time can vary from within a few days to 30 days. This is the ONLY time I wouldn’t treat this as a full maintenance review, but look at these 3 specific things:
    • Any early indications from the support organization that suggests there are gaps in the content? Look at support call drivers, talk to agents, and look at search records for any indication of gaps.
    • Were there any last minute changes that didn’t make it into your content? This could be as simple as last minute changes to labels on an app or on a website. Check in with the product team and make sure nothing has slipped through without your knowledge.
    • Are there any articles that aren’t getting viewed? If so, do you have a title issue or was there a feature that was pulled at the last minute? If certain topics just aren’t getting viewed, perhaps on future releases you don’t write about the subject.
  7. Everything else that hasn’t been reviewed. Again every month run a report, but this time look for articles that haven’t been reviewed for the last year.

To recap, you have triggers based on…
  • Time
  • Agent reports
  • New launches of your products and services and from 3rd party updates
  • Post launch of your products and services

In summary of the process, anytime an article needs an update or review for a potential update, it should follow the critical eye used in every maintenance review. No shortcuts. No saving for later -- later will never happen. Use the triggers I described, so your help knowledge base content is relevant and up-to-date.

What to include in the maintenance review

Now that you have an understanding of the process, this is my recommendation on what to include in your maintenance review. It may seem a bit long, but you are likely already following these practices when you create your content and therefore you’re not doing anything new. There may be a few special cases that I didn't cover that you will need to build into your program, but this should be reasonably complete.

  1. Is the content still required or should it be combined with another article/topic? This is the most important question if the article is getting very few or no page views.
  2. Does the content deliver what the title and metadata description promise? I put this 2nd for a reason. If the content doesn’t match the title, you will need to make a decision on what you will change prior to anything else. It’s wonderful when your articles get page views, but if it doesn’t add value, then what’s the purpose?
  3. Technical accuracy and completeness. Validate the steps -- no shortcuts! This is a culprit for articles that get poor ratings -- something is missing in the steps that the author assumed when they created it. Unfortunately, I find this too often from product experts who are part-time writers.
  4. Grammar and spelling. Forget about how misspellings or poor grammar may make you appear less professional, consider your audience. If you’re a native reader (speaker), you can often overcome grammar and spelling issues, but what if the reader isn’t a native speaker? Don’t make the solution any more difficult than it has to be. If you have a good translation team, fortunately, or unfortunately, they will capture much of this for you but it will come at a cost of time. When it doesn't get caught, then you also get to pay for another translation when it’s finally fixed.
  5. The content is following the latest brand style guide. Work with your marketing or brand team to develop a specific brand style guide for your support website, including your content. While there may be some differences between marketing and support content, e.g. support content is rarely fun, your brand voice should be consistent.
  6. Short, succinct and to the point. Whether your corporate branding guidelines call for short and succinct or not, you want that in your knowledge base articles. Don’t make me read any more than I have to, please! This will also help the non-native-language readers and save you significant money on translations.
  7. Too complex or too simple. A close cousin to short and succinct. If articles are too simple, does it make more sense to include the topic with another article? Don’t make me click more than necessary, but I would trade that over complexity. Remember, if the article is too complex, your customers are going to give up. (If your products are naturally complex, you might try including a label for easy, medium, or hard or an estimated time to read.)
  8. Duplication. This one drives me crazy. What’s worse than duplicate content? Duplicate content that differs based on which article you read. How does your customer know which article is correct? How does Google know which article to list in its search results? In nearly all cases, no matter what the task is, don’t repeat that process in every article, instead, point to a single article that has all the steps. When something changes, it’s much easier to update, too.
  9. URLs, addresses, and phone numbers are still valid. I’m surprised at the number of broken links I find in content because the author was sloppy. A savvy customer might figure it out, but even for them you’ve made it more difficult than it needs to be. For other customers, you might have missed a self-resolve opportunity.
  10. Brand names and product versions are still correct. This gets missed most frequently when it comes to 3rd party software and services.
  11. Any images or videos used are still accurate and helpful. Also, check these against your standards. While bandwidth in many places is getting faster and faster, remember you may have customers in rural or underdeveloped areas where fast throughput is still elusive.
  12. Metadata. Is your content tagged appropriately for searching, sorting, filtering, and reporting? You should have already looked at the metadata description in the context of it matching the content, but it should also be checked for SEO benefit and confirming it has a call to action.
  13. Translated versions are current with the latest version of your master version. Why go through all the effort of having a site in other languages if the content isn’t up-to-date? Some companies will complain that they can’t afford to translate after each update. Can you afford to take more support calls? Remember I assumed you had content governance and QA programs? Each of those (along with short, succinct content) will help reduce your translation costs because you will have fewer updates (which require another translation).
  14. The content was written independently of the display platform. Your content should display appropriately whether in the agent UI, on a customer’s computer, or on a customer's mobile device. You might also be using it in other contexts too, such as in-product help or in a chatbot. Never allow the content display to be fine-tuned by adding custom HTML and/or CSS. If it crept into the article you’re reviewing, it’s time to remove it.
  15. SEO friendly. The most obvious things to check include:
    • Does it make use of headings, subheadings, and bullets?
    • Is it a duplicate of an article that has a better title?
    • Does it have a unique metadata description?
  16. Date, who performed the maintenance review and what updates were made. History is important in case any follow up is required.


While you may not come up with additional triggers or review categories, you should come away knowing that a maintenance program is required. Due to the potential effort required for a maintenance program, having governance and QA programs can help reduce the work immensely, i.e. doing it right the first time will reduce rework later.

Comments

Popular posts from this blog

Active window loses focus

Referencing the value of a cell, not its formula

Firefox Keyboard Shortcuts