of organisations use remote control technologies to provide support.
About the Knowledge Base
Search all the Knowledge Base
Testimonial: I have found that the new HDAA Knowledge Base reduces the time it takes me to research industry stats & reliable information for the ITSM sector. It’s easy to use search functionality encompassing KCS principles, helps to filter & tailor my searches more accurately & there are numerous new services now available through the website. Every time I return to the site there is new information published. Very impressive.
Chris Powderly, Support & Services Manager, Allens
supportworld , support center , service management , workforce enablement , knowledge management , KCS
No Result Found
As you walk through the service desk, you overhear a support analyst say, “That was a new issue.” If you are like most problem solvers, you must learn more. You want to know what the issue was and how the analyst resolved it. You might want to know out of curiosity and also to be informed just in case it happens again.
This is the core concept of capturing new knowledge. Someone has just resolved a new issue and others want to learn about it. While they do not need to learn about it just-in-case, the analyst needs to capture the new knowledge so that others can learn from it just-in-time. By capturing the new issue and resolution as a new knowledge article, the analyst is converting it from a new issue to a known issue. When another analyst receives the same issue, they first search the knowledge base to see if this is a known issue. When they find the new knowledge article, they read it and learn about it just in time to help their customer.
When an incident is resolved, and the ticket is closed, it should be linked to the knowledge article that documents the issue and the resolution. All tickets can automatically be assigned to one of three categories when they are closed based on the knowledge article linkage.
Let’s explore the meaning and value of this categorization.
Before a support analyst attempts to solve an issue, the incident management process dictates that they must first seek to understand what is known by the organization. That is, they are to search the knowledge base to see if the issue is known and has been previously resolved. Reusing the knowledge article will save the analyst time, reduce the mean time to closure, increase first contact resolution rates, reduce the cost per ticket, and increase customer satisfaction. The customer will receive a consistent answer to their question, independent of which support analyst is helping them because the answer is known to the organization and available to all support analysts.
In a mature Knowledge-Centered Service (KCS®) environment, the percent of tickets classified as known should be between 65%–85%. If the process of seeking to understand what is known before seeking to solve (i.e., searching the knowledge base) is consistently followed by all members of the support team, then the first contact resolution (FCR) rate should directly correlate with the percent of tickets that are classified as known. And the more the organization knows, then the higher the FCR.
As additional tickets are linked to the knowledge article of the known issue, the reuse counter is increased. This linkage can be used to document the frequency of the known issue and indicate the need for a problem record to be created and investigated.
Tickets are classified as a new issue when a new knowledge article is linked to the ticket. Since an existing knowledge article could not be found to address the issue, the support analyst is responsible for investigating, diagnosing, and resolving the issue. To the organization, the customer is the first to experience and report this issue and the support analyst is the first to resolve it. It is also the responsibility of the analyst to capture the knowledge they just created as a new knowledge article. The knowledge article was created as a byproduct of resolving an issue for the customer.
For an issue to be known, it must have been captured as a knowledge article. If individual analysts have personal knowledge that is not shared in the knowledge base, then the issue is not known to the organization. The loss of knowledgeable staff can result in the loss of knowledge by the organization. Thus, the best practice is to capture new knowledge within the incident management process before the ticket is closed.
When the issue is resolved and the ticket is closed without linking to a knowledge article, the ticket is classified as unknown. While the issue and resolution may have been captured in the ticket, the knowledge is not available in the knowledge base to benefit the organization.
Unknown implies knowledge loss. While knowledge was created to resolve the issue, it was lost to the organization. If the same issue is reported in the future, costly rework will be required for the next support analyst to investigate, diagnose, and resolve the issue.
Unknown also implies that the desired incident management process was not followed. At least the portion of the process that adds new knowledge articles to the knowledge base was not followed. Sometimes, the support analyst may claim that creating new knowledge is outside of the support analyst’s control. This is usually when the ticket is escalated to level 2 or even level 3 support staff. In this case, the resolution process may not have been provided to the service desk by the support partner. While the improvement process is to persuade support partners to participate in the KCS practices, the support analyst can still minimize knowledge loss by creating a new knowledge article. The new knowledge article will document the issue, and the resolution documents the appropriate escalation process. This issue becomes known to the organization and requires escalation to resolve it.
To learn more about the KCS methodology, HDI offers two KCS certification courses.
The KCS methodology promotes a continuous improvement process known as the new vs. known analysis. The percent of new vs. known vs. unknown can be trended and monitored to evaluate the maturity of the KCS practice adoption. The following chart displays a 12-month trend.
There will be a higher rate of new vs known early in the adoption because the knowledge base is initially empty. When the journey begins, only a portion of the team is following the process of searching and using knowledge for every ticket. As a result, there is a high rate of unknown. The percent of unknown will drop as more are trained and coached to follow the process. The percent of new issues tends to stabilize as the processes mature. This ultimately represents the true rate of new versus known issues reported to the service desk each month. When the known issues become the majority of the tickets, significant value is being realized. In addition to the improvements in incident management, problems will be identified to problem management.
The analysis of the ticket volume leads to continuous improvement.
The analysis of known vs. new can be done at the individual level as well as the team level. This chart looks at four different members of the service desk, all with the same role and responsibilities, over several months.
The new vs. known analysis, when trended, shows you if your organization is maturing in its process adoption. At the individual level, you can quickly see which individuals are following the process and which need coaching. When every member of the team is following the process, then the unknown will be minimized, tickets with known issues will be responded to consistently and efficiently, and tickets related to new issues will result in the capture of new knowledge.
KCS is a registered service mark of the Consortium for Service Innovation.
Rick Joslin has more than 30 years of information technology experience. He has led software development teams and technical support organizations and has provided consulting services to several organizations. Rick has more than 20 years of experience in knowledge management and is recognized internationally as an expert in KCS. Rick holds a BS in computer science and multiple certifications from HDI, the KCS Academy, and AXELOS. He served as HDI’s Executive Director of Certification and Training for 10 years and is currently a 2018 Featured Contributor for HDI. Connect with Rick on LinkedIn.
No Result Found
- Contact Us
- IT Membership
- Support Centre Association
- Comparison Guide
- Price Guide
- Membership Conditions
Training & Workshops
- Training Courses
- Recent Workshops
- Cancellation & Transfer Policy
- ITIL Training
- ITIL Foundations
- Support Centre Consulting
- Service Desk Consulting
- Help Desk Consulting
- Media Kit
- Update your details
- New account
© Copyright HDAA. All rights reserved.
HDAA - Energising the Service & Support Profession
Help Desk Association Australasia Pty Ltd trading as HDAA
T: 1300 130 447 T: +61 (0) 2 9986 1988 F: +61 (0) 2 9986 1330
E: email@example.com W: www.hdaa.com.au A: PO Box 303, Turramurra NSW 2074 Australia
ABN: 20 088 292 755
Our Services: ITIL | ITIL Training | ITIL Foundations | IT Membership | Service Desk Association | Support Centre Association | Support Centre Training | Service Desk Training | Help Desk Training | Support Centre Consulting | Service Desk Consulting | Help Desk Consulting
ITIL® and PRINCE2® are registered trade marks of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
RESILIA™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
The Swirl logo™ is a trade mark of AXELOS Limited, used under permission of AXELOS Limited. All rights reserved.
DevOps Foundation®, is a registered mark of the DevOps Institute.
HDI® is a Registered Trade Mark. HDAA is the Australasian Gold Partner of HDI®.
KCSSM is a Service Mark of the Consortium for Service Innovation™.
Apollo 13 Insignia image by 'NASA Johnson' (copyright-free) June 2017 via https://www.hq.nasa.gov/alsj/a13/images13.html
WEB DEVELOPMENT PARTNER