Knowledge Base Types
You can use knowledge base types to define the nature of the knowledge entry in ASM Core.
Knowledge Base Types are standard in Knowledge Management. They include; Abstracts, Knowledge Centered Support (KCS), Calls, FAQ, and Known issues.
These are the Knowledge Base Types that deliver explicit knowledge to customers and Analysts:
KCS
FAQ
Abstracts (sometimes)
Typically, the following Knowledge Base Types are precursors to a published article as outlined above, in other words, they are the Knowledge Base Types that capture the tacit knowledge and it is the job of the Knowledge Management Team to form it into KCS and FAQ's:
Audience = Editors, Moderators, Contributors, and the Knowledge Management Team
Known Issues
Calls
Abstracts
The following Knowledge Base Types are available as standard in ASM Core:
| Abstract | a loose structure with a title and a body. This is useful for general information, detailed technical articles, and more complex walk-through or troubleshooting guides |
|---|---|
Call | a knowledge entry that has been created directly from a call record. Call entries are used to record knowledge obtained from an incident, problem or known error. This knowledge type can be particularly useful as sensitive information such as client names and passwords can be stripped out and the content made available to a broader audience than would be available if the information was left in the incident, problem, or known error. |
FAQ | a question/answer “frequently asked question” format. An FAQ entry represents a single question |
KCS | an entry in which the problem, environment, cause and solution are written in separate sections. This follows the Knowledge-Centered Support (KCS) principles jointly developed by the Help Desk Institute (HDI) and the Consortium for Service Innovation (CSI) |
Known Issue | an entry structured around an issue description and a corresponding workaround. Known issue entries are recorded for incidents which commonly recur and for which there is a known workaround. This is appropriate for ITIL problem management as they are extremely valuable in resolving incidents quickly. |
You can rename these Knowledge Base Types types, or use them to define your own Knowledge Base Types types.
You cannot add or delete these Knowledge Base Types.
You do not need to use all of the available Knowledge Base Types (you can turn individual ones off)
Abstract
An abstract is a short summary of an issue and its root cause or workaround. It is informative in nature, usually. Abstracts are great for discussing capabilities, Standard Operating Procedures and general information. This is the default KB type in ASM, meaning when you import, imported items will come in as abstracts. Abstracts will usually be part of capturing tacit knowledge but many organizations use them also for explicit knowledge purposes.
KCS
Knowledge-Centered Service (KCS) describes a way of interacting with knowledge which enables teams to:
answer questions quickly
deliver answers where people are looking for them
train new employees faster
Additionally, KCS provides insight into which questions are being asked the most, and identifies recurring problems so we can remove them from the environment.
You will create a KCS typically, as a result of Problem Management and aggregation of similarly themed KB articles. KCS articles are representative of bodies of knowledge and concepts that apply broadly or generally (troubleshooting principles) rather than the ad-hoc tacit knowledge that is being captured "on-the-go" we typically think of when considering content for the KB.
Many organizations choose to only enable this particular Knowledge Base Type.
Call
Call is a type of Knowledge Base entry designed to capture tacit knowledge from agents and make it explicit. These KB entries will typically be aggregated into a KCS article, eventually by the knowledge management team. The Call forms step 1 of the process of capturing tacit knowledge for the organization. For this reason, most organizations make this a draft process and Calls are reviewed by the knowledge management team.
Do not create a separate knowledge entry (of any type) for every call that is encountered. Rather, call knowledge entries should be used to represent typical calls on a particular topic. It is recommended that calls on similar topics be aggregated into a single entry (KCS) by the KM team.
Ensure you remove all Call attachments that may have been linked unless they are necessary to support the KB Article and if the finished article will be customer facing - no information relating to a specific customer should ever be left attached to a KB article.
FAQ
FAQ are ubiquitous to most organizations and many times, end up not being used as frequently as we would like. Frequently Asked Questions should truly be frequently asked. This forms step 2 of the aggregation of Call, Abstract, and Known Issue KB articles. Will they become a KCS, or an FAQ? You should aim to have a list of FAQ appropriate for the organization but not so massive as it cannot be utilized effectively.
Format the title of your FAQ as a question using the most likely key words a customer would use so that it can be found in searches.
Ensure you remove all Call attachments that may have been linked unless they are necessary to support the KB Article and if the article will be customer facing - no information relating to a specific customer should ever be left attached to a KB article.
Known Issue
Known issues are problematic for organizations and result in many extra man-hours of work each year. Documenting Known Issues for eventual incorporation into FAQ or a Known Issue list is vital to lowering the total cost of support and will allow Agents to focus on providing the support that is really needed. For example:
You could publish a known Issue list with links to each known issue.
You could setup Known Issues in the Major Incident Widget (Self Service Portal Settings (Partitioned)) and allow users to Add themselves to it. This will give you a very good idea of the impact of the known issue and can help you focus on the ones that are most impactful first.
You can aggregate known issues into FAQ and KCS so that users and Agents can find and implement any workaround quickly and easily.
Things to remember when creating a Known Issue:
Format the title as synopsis of the issue, not the symptom, using the most likely key words so that it can be found in searches. For example, "Chrome Memory Leak"
You will describe the symptoms and related issues in the details.
Link the ticket to the Known Issue KB Entry.
Ensure you remove all Call attachments unless they are necessary to support the KB Article and if the article will be customer facing - no information relating to a specific customer should ever be left attached.
Renaming a Knowledge Base Type
Select Knowledge Base Types to display the Knowledge Base Types window. (You may like to adjust the column widths to see all of the columns.)
Select the base type you want to rename in the browse table.
Overwrite with the name you want to use.
Setting the Visibility of a Knowledge Base Type
You can set each knowledge base type to be hidden or visible throughout the system, such as when adding knowledge entry types, creating a new knowledge entry, and also on the search criteria panel in a knowledge search. All base types are set to visible by default.
Select Knowledge Base Types to display the Knowledge Base Types window.
Select or clear the Visible checkbox for the base type(s) you want to hide/display. (You may like to adjust the column widths to see all of the columns.)
