Known Error

[Stacey Brannan]

Looking for advice from anyone that may have an established mature Known Error process in place. We are working on putting in a formal process around Known Errors.

What I know:

Only one Known Error knowledge article can be created from and related to the Known Error Problem record. 

Incidents related to the Known Error knowledge article automatically get related to the Problem record on the backend to help us track and understand impact level, which is a valuable part of the Problem Management Known Error process.

What we currently have in place for Incident/Knowledge relationship process: 

• We have knowledge bases setup by audience - one for Level0/end users, one for L1/Servicedesk, L2 and 3 teams have their own individual knowledge bases.
• Servicedesk is required to relate Incidents to KBs they use to resolve a call at first level. If they escalate the Incident to L2 they typically do not relate to a KB. 
• Some L2 teams will relate the KB in their knowledge base to the Incident but it is inconsistent.

Where I need help:

If we have a Known Error that includes steps for multiple audiences, how is that best managed to ensure all related Incidents get related to the Problem record? 

• Example: There may be a workaround that requires a user to contact Servicedesk, Servicedesk has workaround steps they can try but if they don't work, then it has to be escalated to L2 who has additional steps only they have the access and knowledge to perform. 
• If we only put L0/End User workaround steps in the Known Error article then how will all the Incidents related to KBs in the Servicedesk or L2 knowledge bases ever get related to the Problem record?  How will one know from reading the Problem record these other KBs may exist as there's no way to create multiple relationships to them?

Looking for recommendations on how to implement the Known Error process so we get the expected value from it and have not found much guidance that gets this into the weeds. Thank you.

[bammar]

Hello, I didnt see anyone try to answer so I will humbly pass along some thoughts to consider here. im just going to type what comes to mind of how I would break this down. 

Lets use an example scenario - Issue - Everyones voicemail records have been deleted but can be recovered in MOST cases. 

How it may play out -- Support is having a normal day and 10 Incidents come in at once about this- They decide to create a Problem. They alert all Support staff to attach all incidents regarding voicemail deletion to this Problem and inform the callers IT is looking into it.  (To my knowledge Incidents should be related to the Problem and thats how I have done it in organizations past. Especially because the KB article is not created yet and solution may take time. )   2 hours later 100 Incidents are attached to this and the company sent out an email saying they are aware ... A Tech has come up with steps the users can try to resolve and created a KB .  At this point that KB is attached to the problem. You may have to consider putting the steps to fix for MOST users and then at the end say - if this works close incident , if it does not update incident or call IT for further steps aka Level 2. You can make other articles if you want with the L2 steps for IT consumption. I am not sure about the mechanism to communicate from KB to Incident however I do know you can broadcast a message within a Problem to all of its attached incidents. 

    Most of the reporting I have done regarding large scale issues has been by having the Parent Problem  and seeing how many attached incidents, this way you get an easy picture of the scale - not to mention the Knowledge article may be used for mitigation for sure- someone stumbles on it without opening a ticket for instance but not in all cases- a subset of the total - agents may have memorized those steps and spoke to someone over the phone- there may be a grey area if you would credit the KB here and if it would be redundant when you can use the Problem field.  Additionally you could use the Viewed and Helpful fields in the KB to gain info. IE if a Problem had 100 incidents and 10 kb views that means 10 or less were helpful.   Finally if a decision was made to resolve all the incidents with the steps in KB- agents could paste that in the closed.   I just wanted to provide some discourse here that hopefully helps you get closer to a solution your happy with.