One of the ways BMC Customer Support tries to enable customer success is by maintaining a knowledge base which grows and evolves as we work customer-reported issues. We follow many best practices to ensure the knowledge is captured, reviewed, refined and updated as new knowledge is collected. I will list examples of those processes below and some of the trade-offs we encounter when following them.
In the spirit of continuous improvement, I would like feedback on areas to focus to deliver greater value from the knowledge base. I expect the answers differ based on particular product areas, so I will post this discussion topic in product communities too so we can understand the best place to focus for each of them. Keep in mind that general feedback does not help me here - we will be always improving the knowledge base - I just need guidance on where specifically to focus those efforts.
Here are some of the processes we follow, and limitations or considerations as we perform them:
We search the knowledge base as we work issues, and we re-use and send that knowledge to customers if it is relevant. We don’t use a separate or internal database – we use the same one though it does include articles which have not been reviewed or published yet.
If the customer has follow up questions not addressed in the knowledge article, we update the knowledge article (KA) to answer those questions and make it more complete, and then send the KA changes for review and approval. Limitation: We can’t cover every possible follow-up question in the KA, so there is a decision we make on whether the question/answer is better answered in another place and potentially, referenced. How are we doing as a rule, with how we make those decisions? Do you need to find multiple KAs to get a complete resolution, or do you find KAs are overly verbose trying to cover corner cases which are never encountered?
If the customer searched but was unable to find the knowledge article, we look at the customer search history and if appropriate, add the search terms to the KA. We also look at the issue summary and description to determine if the knowledge article should be updated to be more findable – to include alternate descriptions or symptoms. Limitation: Sometimes problem descriptions are more detailed than the searches in the knowledge base. Unlike Google which can suggest common search terms based on billions of searches and find the most popularly used resource, the goal of searching the technical knowledge base is to find the most specific match rather than the most popular. Automating or habitually adding addition search terms can have adverse effects that are difficult to reverse.
When we find new knowledge not appropriate to add to an existing one, we create a new knowledge article even if the circumstances in which it would be useful are very narrow, or if the solution is particular and not applicable to most customers. These remain unpublished knowledge articles unless they are considered useful to several customers. Limitation: Reviewing and publishing every partial piece of a knowledge from corner cases would increase the volume but lower the quality overall. It may be a worse experience to review lots of KAs which do not apply. On the other hand, a narrow situation may turn out to be encountered by several customers so we use the following process to identify those cases. After a knowledge article has been referenced by several issues, we move to develop, review, and publish it. Is this an effective process, or are we too late with getting the knowledge reviewed and published?
Developing the knowledge article means adding explanation and detail so the reader can evaluate the applicability and usefulness to their situation. The product name, version, and steps leading to the issue are added plus information about the root cause, work around, or solution to it. Limitations: Are we providing the required level of detail in the KAs to evaluate the applicability and to use solutions? Or do overly specific details and context information make it difficult if it applies?
Reviewing the knowledge article is a final step before publishing it. A knowledgeable colleague checks if there are unwritten assumptions, grammatical issues that make it hard to read, or other gaps that would impact the usability of the article. Limitations: The colleague is on the same Support team and may have some of the similar assumptions or technical writing habits. On the other hand, having a non-technical reviewer focus specifically on grammar would miss technical gaps, and would introduce more steps and greater delay in publishing. Is the quality of review sufficient, or is it the main hindrance in recognizing value from the knowledge base?
The knowledge search interface is intentionally simple without a lot of fields to populate, so you can just use them as search terms in a question. Search guidelines are provided to understand different ways to search. Limitations: Are there additional ways you would like to search, which are not included in these tips?
When a knowledge article is published, it should include the product version to which it applies. The KA may also apply to future versions of the product – for example, service packs and minor versions rarely change the design or interface steps. Our process of leveraging and updating the knowledge base as we work issues includes updating versions, but not specific service pack levels. Limitations: There is a diminishing return on this activity since it requires validation on new versions, and defects and exceptions are often addressed in Service Packs. Is more focus on updating knowledge articles about which additional versions it applies to the biggest area where we can improve the knowledge?
Customer Support reviews product documentation for new releases which covers changes in the release. As part of this process, Customer Support makes decisions whether customers may experience these changes as exceptions, may not recognize the relevance of the note in the product documentation, and instead search the knowledge base for solutions to issues in the new release. In these cases, we create knowledge articles that describe the issue, how it is encountered, and where to find more details on it. Limitations: There is a diminishing return on this activity because the information is already documented, and it does not make sense to cross-document every issue. The search engine also searches documentation, so it should be able to find the same information in that location depending on the search terms. Are we finding the right balance of making the information available from the knowledge base versus duplicating information which describes the issue slightly differently?
The initial goal of a knowledge article regarding defects is to provide the information as quickly as possible to save effort investigating a known issue. In some cases, the knowledge article will reference a defect and indicate it will be included in the next service pack. As service packs are released and defects closed, the knowledge articles are updated to include the service pack level which contains the solution. Is this process working effectively, meaning do you find the required information about defects and the version which contains the solution, or is this the area which would provide the greatest value in improving it?
For products which have a long life and many versions, the number of knowledge articles for older versions grows over time and may not apply to newer versions as the product is improved and addresses these situations. Searching for knowledge articles using the version number in the search terms should find the KAs of the desired versions so customers can find articles relevant to their product version. Limitations: Archiving or deleting the old KAs would impact customers with legacy versions, but may improve the behavior for customers running the latest version. Is there a good balance of these two competing requirements, or is this the area that needs to be revisited?
External users of the knowledge base have an option to provide feedback on knowledge articles - areas to be clarified, corrected, or reviewed. This is a complementary process to the one described above, where Customer Support continually uses and improves the knowledge base. Limitations: This feature is rarely utilized by customers, which may mean the articles are great or that users do not care to provide feedback. Is this an area which you would like to contribute if it worked better or differently, or is there no interest in making such corrections? This feedback would help define whether this is a priority to improve or not.