The new vs. known analysis is an example of the continuous improvement processes in the Evolve Loop. The new vs. known process can help assess the health and effectiveness of a support organization’s KCS practices. This is an example of the kind of process the Knowledge Domain Expert (KDE) would facilitate.
The goal of KCS is to capture and reuse the knowledge gained through customer interactions – solve it once, use it often.
Ideally, we would like to use our support resources to solve new issues, not known issues. As an organization adopts KCS and integrates use of the knowledge base into the problem-solving process, we see the internal reuse of knowledge increase and we can establish a baseline for the new vs. known ratio. As we start to deliver knowledge to customers through a self-service model, external reuse increases and internal reuse should decrease; we are solving known issues through self-service. Understanding the ratio of new vs. known incidents becomes an indicator of the health of the knowledge flow and the effectiveness of the self-service model.
Identify opportunities to reduce the resources spent on known issues and accelerate the resolution of new issues.
- Reduce the resources spent on known issues. This is a function of improving customer use and success with the self-service model.
- Improve the speed and accuracy in solving new issues. This is a function of getting the right resources working on the issue as quickly as possible.
By looking at incidents closed from the perspective of new vs. known and analyzing incidents in each category we can identify:
- The percentage of new vs. known issues being worked on in the support center. This creates a baseline against which we can measure the impact of future improvements.
- The characteristics of known issues and assess why they were not solved through self-service.
- The characteristics of new issues and identify opportunities to improve the speed and accuracy of the problem-solving process.
The scope of the analysis should include the following:
- Support centers for internal and/or external customer support
- First point of contact (level 1), first point of escalation (level 2), second point of escalation (level 3)
- Hardware, software, networking, services
The new vs. known study is something that should be done periodically over the course of a year, probably not more than once a quarter.
The study is done by product area or product family; it is a sampling technique. It is recommended that you do a pilot with two or three product areas to get a feel for the process. For the pilot, it is ideal to have the group of SMEs together in a conference room for a day. This allows you to discuss and resolve points of confusion quickly. Follow on analysis can be coordinated via conference calls.
Guidelines and definitions for assessing incidents
(Columns in the sample spreadsheet: click here for spreadsheet or see attachments below)
Primary fields (relevant to most organizations and important to the analysis):
Relevant incident? - no or blank
- Is this incident relevant to the new vs. known study?
- This is a way for people to flag incidents that should not be included in the study data. For example, incident is written in a foreign language (can’t be read), incident was closed by customer without resolution, incident was duplicate, incident was administrative
Incident has an article linked- yes or no?
- Yes: an article is linked to the incident (doesn’t mater if it is correct or not)
- No: nothing is linked to the incident
Pre-existing article or document linked to incident (known) - yes or no?
- The article linked to the incident existed before the incident open date (the article was not created as a result of this incident)
Known but not captured (optional) – yes or blank
- Tribal knowledge (things that are known by all) but are not in the knowledge base. Capture the obvious ones, it is hard to know what is known but not captured, don't spend a lot of time trying to figure this out.
Correct article or document linked to incident – yes or no?
- Yes: the article is relevant to the incident. Does the resolution in the article solve the issue documented in the incident? Diagnostic articles may be linked but a Y should be entered only if an article is linked that includes the resolution.
- Linking to a “formal document” (like a diagnostic guide or installation guide) is fine so long as the Support Analyst didn’t add any value to the answer and the link can be done to the specific sentence or paragraph that provides the resolution
- No: an article is linked but it is not specific or relevant to the incident
- Blank: no article linked to this incident
No article linked but one existed – yes or blank
- An article was in the knowledge base when this incident was resolved/closed
Article linked is “internal use only”– yes or blank
- Yes: the article will never be visible to customers. It is a security risk or technically too complex for customer user; it is visible only to Support Analysts
Correct article was visible to customer – yes, no, or blank
- Yes: resolution to the issue documented is in an article that is visible to customers
- No: article exists but was not published to the web. Article is still in draft or approved state and has not made it through the life cycle to be visible to customers yet
- Blank: no article exists
External article or document – yes or blank
- Yes: an article for this issue is available and visible to customers (it may or may not be linked to the incident)
Secondary fields (may not be relevant to all organizations and not critical to the objectives of the analysis):
- Diagnostics include any diagnostics: general systems diagnostic tools or product specific diagnostics that had to be run to collect additional information. Do not include the use of system logs or data the system normally captures
Required problem recreation
- Support recreated the problem in a lab
Required problem recreation by the customer
Required collaboration with others
Multi-vendor (MV) information/documentation required
Multi-vendor (MV) contact required
Hardware, field dispatch required
Hardware, parts ordered
- How to or usability questions
What it took to fix
- Time to resolve (work minutes, if available)
- An escalation (L1 to L2, L2 to L3)
- Collaboration (conversation, IM, email, other)
- Recreate the issue
- Ran diagnostics