The all in one customer engagement suite
Best practice to reap the most from your knowledge assets
By clicking on "SIGN UP FOR FREE" you agree to our Terms and acknowledge having read our Privacy Notice
Knowledge management is one of the most important, yet underutilized, capabilities in your IT Service Management (ITSM) functions. Every day, your support teams learn new insights about your systems, services and the people who use them. In many organizations, the IT service desk and the teams performing support operations have a more comprehensive perspective on your companies’ use of technology than the CIO and the people who designed the system. This is because they see not only the technology but also interact with users and see how the technology is being used.
Knowledge is not the only resource your support agents will need to solve user problems – skills and experience are important too. Knowledge is the information people have available to them. They may have discovered it themselves or someone may have provided them with the information. Skills are the agent’s ability to take the information contained in knowledge resources and apply it to a specific situation or problem. Experience is the culmination of previous encounters, observations, and events in which agents have utilized their skills and knowledge. Being an effective support agent requires all three.
There are many places where knowledge management can be applied within your service management and helpdesk functions – and not just support. To understand these application opportunities, treat knowledge management as an overlay function of all your ITSM processes. Each process area can create knowledge resources, improve them and/or consume knowledge to improve productivity. The knowledge articles and other resources created in one area (perhaps, the helpdesk or incident management) could be used in other areas (such as problem management or solution design) and vice versa. Knowledge should be treated as a shared resource available to benefit your entire organization.
nowledge management in ITSM isn’t only knowledge articles, captured and maintained in the knowledge management database (KMDB). The knowledge resources available to your organization are much broader than published articles. Your knowledge-management processes should seek to integrate as many sources of knowledge as possible. Some of the most common sources of knowledge available to your ITSM functions (in addition to published articles) are:
Your support ticket records, including descriptions, notes, and user interaction records, contain a wealth of information about not only the issues users face but also technical details about how your IT environment is constructed. Ticket data is likely your greatest source of knowledge about your IT environment. Most ITSM and helpdesk systems offer capabilities for performing keyword searches against ticket data (not just knowledge articles) to help your agents identify similar issues their peers have seen previously. Key pieces of ticket data you should be leveraging include both text notes and any references to users, configuration items (in your CMDB), linked knowledge articles and monitoring/diagnostic data.
Most companies have enabled search capabilities for both end users and support agents to help them find various knowledge resources. The records of these searches are a resource themselves. Search history provides insights into what type of issues people are experiencing, the information they are seeking and, most importantly, how they are describing their problems. If a search results in the user finding the resource he or she wants, then that is an excellent outcome. This indicates you have a knowledge resource and you know its use. If the user searches again (because he or she didn’t find what he or she was seeking), then you now have insights into the user’s description, which can help you better craft your knowledge articles. Common search terms are also useful information for prioritizing bug fixes and developing FAQ pages.
New-hire documentation and the reference materials provided when your support team took responsibility for a system are excellent sources of information about how systems are intended to operate, the anticipated maintenance tasks and routine administrative activities. Most helpdesk and ITSM functions have a library of these training documents, but often, once someone is trained, the resources are rarely used. Training documents should be included in your entire knowledge repository, managed and maintained as if they were knowledge articles, thus ensuring they can be accessed and utilized at any time.
Most system releases’ patches and installations include a set of release notes, which explain the changes in the recent version. This includes a list of fixed bugs and issues and new features made available to users and capabilities that have been deleted or retired from the software or hardware. Operations teams performing the installation and change reviewers use these resources frequently, but they are often overlooked sources of knowledge available to support resources. Release notes often include valuable information to help determine what changed in an environment – aiding in the diagnosis of incidents and identification of the root cause of problems.
Most implementation teams maintain a library of test cases, automated scripts and, often, diagnostic tools that are used during the software development process. As pre-release testing is performed, these tests are executed, and the results logged. Both the test scripts and testing records are knowledge resources that can aid your support and operations teams in running and maintaining the services. Test cases and automated scripts can be used as diagnostic tools to determine when the production system is not functioning as it was intended. Benchmarking current tests against pre-release test results can also help support teams focus on specific functions that are not working properly.
Most hardware and software is released to users with bugs, defects and missing features of which the development teams are aware, but have not yet addressed. This could be because the risk and impact of the defects are deemed acceptable or it could be because there was not enough time and resources to address the item before the component was released. The known-issue database for your systems, which development teams maintain, is a valuable source of information for support teams. If a user submits a ticket for an item already logged as a known issue, then typically a detailed diagnostic must be performed to identify a root cause. A short-term fix or workaround can be suggested instead.
Not all your knowledge sources are electronic records. It is important to understand which subject-matter experts are available, either within your service management teams or in the broader support ecosystem. Subject-matter experts may have knowledge, skills, access or experience to address issues that are either especially difficult or simply have not been documented sufficiently for frontline agents to resolve themselves. It is a good practice to capture knowledge from your subject matter experts to reduce the organization’s reliance on individuals, but there will always be a human-knowledge component to IT service management.
Knowledge articles are the core set of knowledge resources your support team and end users use. Well-written knowledge articles will make searchability and readability easy and enable the reader to diagnose and resolve effectively the issue he or she is facing. A poorly written knowledge article will cause frustration and could potentially cause harm to your data or IT systems. Here are some best practices for creating knowledge articles:
Length – Knowledge articles presented to end-users should be one-half to 2 pages (300–900 words), depending on the complexity of the topic. Articles less than 300 words will not contain enough content for keyword searchability while articles of more than 2 pages are likely to lose the reader’s attention.
Content – Each knowledge article should pertain to a single topic or address a single situation. This aids in searchability and helps direct readers to the specific topics they are seeking. Troubleshooting guides, release notes, and other knowledge documents should be separated into individual topics when recorded in your KMDB, so each article can be managed independently.
What to include – Knowledge articles should include a concise overview of the situation or problem, a description of what outcome the article describes, any constraints (such as special access levels required) and a clear set of steps for the user to follow. Depending on the expected skill/experience level of the reader, articles may include technical diagnostic steps or they may just include a few basic tasks and instructions on how to seek assistance from a support agent.
What not to include – When creating knowledge articles, never include any sensitive system information, such as usernames and passwords, that could compromise security. Also, be aware of the data that is being accessed (such as system log files) and the security considerations for this data. If the article suggests a user provide data to an agent, then only collect personal information if you have a means of storing it and controlling access appropriately.
Tone and language – The tone of knowledge articles should be direct and concise, providing enough information to be effective without being overly verbose. In some organizations, localized language content may be necessary. If so, then ensure you have an easy method to filter knowledge articles based on language.
Intended audience – Defining the intended audience of a knowledge article requires some forethought. A technical article for a support agent or IT engineer will be very different than an FAQ article for business users. If the content of an article is suitable for multiple audiences, then it may be helpful to create multiple articles (one for each audience) to customize the tone and language.
Tagging articles – Meta-data tagging of articles can be an effective means of enabling navigation and browsing of knowledge content. Because modern search technology can perform keyword matches against text fields, such as titles, descriptions and article body text, tagging is less important than it was a few years ago. Tagging may still be helpful in situations where you need to identify knowledge articles related to a specific audience or a specific systems release.
Searchability – Modern search engines have powerful keyword matching capabilities that can help users quickly find the resources they want; however, there are a few steps you must take when creating articles to help search engines work effectively. You must be sure to use the keywords users would be using to search for your article. Keyword density is the best way for search functions to find an article. You should also avoid using keywords for topics, subjects, etc. that don’t apply. For example, a phrase, such as “This article wouldn’t apply to XYZ,” would cause the article to be found for a search of XYZ.
The knowledge articles you create are like a raw material – their true value is revealed with refinement and how they are used. This process is called knowledge curation. The purpose of knowledge curation is to transform the created and captured knowledge resources from other sources into a library of knowledge that is complete, consistent and easy to use. It’s best to use knowledge management best practices throughout the curation process.
Knowledge resources can be obtained from different sources. Some knowledge content is created in the form of articles, other content is distilled from documentation and some is acquired from external sources. Knowledge aggregation is the process of gathering the various input sources and combining them into a single library of resources. This often requires addressing duplication and format differences and merging different data structures. All your knowledge content should be aggregated and reconciled to a common format to enable consistency and searchability.
Knowledge articles don’t exist in isolation, they are related, for example, to configuration items, releases, business processes and user roles in your IT environment. Each knowledge article should be properly classified and mapped to its related dependencies. This will enable better searchability and maximize the value of the knowledge asset.
Often, the content an author writes in the draft of a knowledge article requires editing and review before being published. Content refinement should include checks for completeness, language and tone, accuracy of diagnostic activities and appropriateness of recommended action steps. Another good content-refinement practice is to have subject-matter experts conduct peer reviews while still leveraging content developed from across your organization.
Different audiences need different types of knowledge resources. Business users, technical support staff and vendors each have unique needs and often require customized knowledge resources for effectiveness. Each knowledge article should be targeted to a specific audience and refined for language, technical skills, and access levels appropriate to the audience.
Knowledge resources are often presented in the context of support portals, ITSM systems, FAQs, troubleshooting guides and search forms. While the data presented through each of these presentation mediums may be the same, the manner in which the data is formatted can vary. Effective knowledge curation includes making sure knowledge articles and other resources are formatted appropriately for each presentation.
Knowledge curation does not end when a resource is published. Knowledge stewardship and the curation activities also include continuous improvement activities and periodic re-evaluation of the usefulness of knowledge resources. Every knowledge article has a useful lifespan – continuous improvement activities should seek to maximize the value generated during the life of the article and then identify the appropriate time for the resource to be retired.
Some of the data in your knowledge-management database aren’t meant to be shared openly. While certain information is necessary to support your IT systems and users, it may contain some data that could be harmful in the wrong hands. In addition to helping to distribute data to the right people, your knowledge-management system must also have the capability to restrict access to sensitive data. Knowledge stewards are responsible for managing access control to knowledge resources. You should consider restricting access to these types of sensitive data and others that apply solely to your company:
Security risks – Your support team must be aware of security risks and vulnerabilities with your IT systems in addition to the conditions that could cause them to be exploited and the potential impact if they are.
Configuration details – Your CMDB and many of your knowledge articles may contain details about the components used in your IT environment and how they are configured. Configuration data, if not controlled, can be used to find and exploit vulnerabilities in your systems.
Personal data – End-user personal data should not be stored openly in ticket notes or included in knowledge articles. If you do store personal data, then it must be secured and access-restricted to only those personnel authorized to view it.
Vendor data – In IT environments where multiple vendors compete for your business, knowledge resources about what vendor components you are using, known issues with them and their use can be a potential source of unfair advantage in a competitive bidding situation. If vendor data is included in your ITSM system or knowledge repository, then access should be restricted to the appropriate parties. Vendor contact data should also be secured to prevent unauthorized users from requesting support services under your company’s vendor contracts.
Cost of services – Service and component costing data should not be included in your knowledge-management resources. This data can be easily manipulated to undermine vendor contract negotiations. Although access restriction is an option, best practices indicate it is better to keep cost data separate from your operational data.
Many companies have adopted a partner-ecosystem approach to IT service management, which includes a network of relationships with component suppliers and support vendors. For these relationships to be effective, some knowledge data must often be shared outside of your company. Knowledge-management best practices suggest knowledge sharing be done in a controlled manner with both contractual and operational safeguards in place. At a minimum, those safeguards should include:
Non-Disclosure Agreements (NDAs) – These are commonly included as a part of contract terms and often extended to individuals within the vendor organization. The purpose of the NDA is to establish a contractual framework to allow vendor personnel to access your company’s data and resources and to govern the use of the information they obtain. Specifically, NDAs should restrict the use of your data to activities that directly support the activities of your company.
Controlled environment – A common technique for restricting access to knowledge resources is to make the data accessible to 3rd parties through a controlled environment (such as a Web portal) where your knowledge stewards can provision, monitor and revoke access to individual users or entire companies.
Filtered data - Filtering knowledge content based on job role is a common practice in knowledge management and curation. You can use the same technique to differentiate content intended for support staff vs end-users to filter the knowledge data available to vendors or other 3rd parties.
Your company’s knowledge resources are assets. Like other assets, they have a finite useful life and there are events that impact how individual pieces of knowledge progress through their lifecycle. In many cases, the lifecycle of your knowledge resources will be directly related to their associated underlying systems. As your systems evolve, your knowledge must evolve as well.
Releases, deployments, patch releases and configuration changes each impact the systems in your IT environment. As changes are made, knowledge articles, documentation and other resources related to those systems may need to change as well. For example, if a user interface is changed, user documentation, troubleshooting guides and diagnostic steps captured in your knowledge-management database may need updating as well. Bug fixes and patch releases may also resolve underlying issues, enabling you to retire knowledge articles related to managing known issues. Each release and/or change event should trigger a review and update of related knowledge resources to ensure your knowledge-management database is always complete and current.
In addition to updating knowledge when changes occur in your environment, knowledge-management best practices suggest you should conduct a holistic review of your knowledge repository periodically (once per year at a minimum). During this review, you are viewing the big picture to understand what resources are used most frequently, where content is located that isn’t being used and where you might have gaps in knowledge resources (reviewing search history can help with this task).
Your knowledge-management database should increase as you capture more information and integrate more resources. Periodic reviews should include classification, prioritization, and curation of content to ensure the most valuable resources are readily available. This is also a good time to archive knowledge articles related to retired or replaced systems, so they don’t clutter your knowledge database.
Just like your IT systems, your knowledge articles should evolve as you learn more. Best practices indicate designating knowledge articles by versions enable changes to be applied while retaining their history. Your knowledge management system should support both the designation of articles by versions and status to represent stages in the knowledge-management lifecycle. A new article may be created as a draft, be reviewed and published, and then a similar workflow is used for subsequent versions. When the article is not needed, it should be archived (not deleted) in case it is needed as a future reference. Although your knowledge articles may have multiple versions, most consumers of the knowledge will only need to see the most current version. Your knowledge management and search functions should be able to filter older versions.
Knowledge is a resource the organization owns, not an individual; however, an individual could be responsible for managing and maintaining knowledge resources. Knowledge-management best practices suggest you should assign a steward for each article and resource in your knowledge-management repository. Knowledge stewardship is a similar concept to data stewardship your company already uses to manage sales data, customer records, financial data, etc.
The steward is responsible for both the content of the knowledge resource as well as managing who is permitted to access it. In some organizations, subject-matter experts or members of the support team are assigned as stewards of knowledge resources. In other organizations, knowledge stewardship is a separate role. There are benefits and drawbacks to either option, but what is important is that the role is clearly understood, and someone is accountable.
Knowledge management is the capture of individual and available pieces of information and organizing them, so others can benefit. Leveraging knowledge-management best practices can help your company more efficiently capture your available knowledge resources, manage knowledge as a company asset and use knowledge to improve the quality and performance of your support operations.
Getting Started with Knowledge Management
5 things you never thought will make your end users happy
11 Capabilities to Consider for IT Self-Service
What can service management learn from product management?
Start your 21-day free trial. No credit card required. No strings attached.
Sorry, our deep-dive didn’t help. Please try a different search term.