KCS - Knowledge Management - Linking Incident Resolution
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-27-2015 07:46 AM
- Large University
- 500+ calls daily
- Currently on Dublin, upgrading to Fuji end or year
- Using the knowledge module
- Looking to implement Knowledge Centered Support
Currently we are able to link Incident Resolution to Knowledge Articles, but only if the article is attached to the incident graphically. Meaning, we can attach the article in it's entirety and send that back to the customer. We want to tie incident resolution to articles, but don't always want to send the customer the article as it appears. Some of our articles contain multiple solutions, or have information intended just for the ServiceDesk. In the implementation of KCS, one requirement is the tie between resolution and knowledge. Eventually we would like to require a tie to a KB for all resolution, even if we need to create a catch-all article for those unique situations in which there isn't a good fit (eventually using the lack of an article as a reason to draft, implementing the demand-driven model). I would like to produce metric reports around resolution and knowledge use.
Here's my question:
How can we increment or tie our knowledge base articles to incidents without having to wholly insert them into the incident notes?
Thanks in advance, I'm hoping I'm overlooking a very simple thing and the answer is "duh, just do 'this'"
Steven Meads
University of Minnesota
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-04-2016 11:13 AM
dylanyoung Dylan, apologies, it's been a while since I've visited the community forums!
We are still in process of planning, with our development requests moving forward.
We've settled on altering the out-of-box from inserting (attaching) the whole article and instead have a link added to the Work Notes field. This increments the Use Count, while giving our Tier 1 folks the opportunity to copy it our to the customer if needed. We found that inserting the entire article, in many cases, came across as impersonal.
Right now we're looking to alter our roles in SN to better fit the KCS model. The roles we're using now (Knowledge, Knowledge Admin, Knowledge Manager) were too restrictive. I was actually back here to post a different question. Maybe you've got an opinion?
I'm wondering if we should create new roles to fit our KCS model (contributors, coaches, etc..) or try to alter the out-of-box roles to better match?
I'll check back more frequently, and will have more data once we've implemented in December. Right now we're starting our design sessions for content standards, performance indicators, roles, etc...
Cheers,
Steven
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-04-2016 11:14 AM
Whoops, didn't answer your question about unlinking. We haven't crossed that bridge yet. Right now we'll be factoring a margin of error on the linking part.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-07-2016 04:51 PM
Hi Steven,
Thanks for the reply. Sounds like you guys are making progress which is important, whilst learning from what you've done so far.
Agree that automatically attaching a knowledge article to a customer facing communication does present agrogance, especially as you can't control the expectation/attitude to your end users around self-help knowledge. Very dangerous to make that Out of the Box IMO, as it takes a lot of work to educate and win over any customer base to a self-help model.
With the roles, we are in the same camp. I was tossing up whether to build upon the OoB roles you mentioned or parking those and introducing fully new ones. I've handed over that decision to our ITSM tools team, but have given them a brief that what we want to ultimately see is only 5 roles with very specific permissions and workflows:
- Candidate (read, flag, link)
- Contributor (add, edit and approve)
- Publisher (end user publish, retire)
- Manager (config categories, pin articles)
- Owner (config knowledge bases)
We are also in the same boat with regards to the workflow states of KB records as the OoB ones don't comply with KCS and actually inhibit our process and culture.
Will report back once we've introduced these and have been working with them for a few months.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎08-08-2016 07:54 AM
Great stuff,
As our project moves ahead I'll keep you in the loop, also good to have another to bounce ideas off.
Thanks for the reply!
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
‎12-28-2016 01:04 AM
Have you set up roles for candidate and contributor?
And did you find any solution to make the workflow states comply with KCS?