Does anyone uses an Out Of The Box knowledge feedback task implementation?

[Johan van den H]

We are using knowledge feedback and knowledge feedback tasks (which have been setup like explained in the ServiceNow documentation)

However it is not clear what should happen (OOTB) once a feedback task has led to a new version of an knowledge article.

The ServiceNow documentation states:
Resolve the feedback task

In the Resolution Code field, select the code for resolving the article. In the Resolution notes field, enter the reason for the resolution and click Update. An email notification is sent to the feedback submitter. The email notification includes the portal URL for the article from where the feedback submitter can accept or reject the feedback.

However, on my PDI I seem to miss the notification flow which informs the feedback submitter that a new (version of a) knowledge article is ready to be accepted or rejected.

Does anyone use this OOTB flow?
And if not, how do you inform the feedback submitter that he/her feedback has been processed?

In the OOTB flow the feedback submitter also does not get a confirmation notification mail that his/her feedback has been received and will be processed.
The contact with the submitter is only through notification mails as the feedback task is not shown among the regular requests on the portal.

Should this valuable feedback not be treated like other requests to make the handling more transparant for both the submitter and the handler?

[Mike Van Vooren]

We use the OOB Feedback Task workflow.  We also have Versioning and Instant Publish turned on.  So, no approvals for new versions. 

The email notifications for the submitter are typically just informative.  In other words, they get one to let them know their feedback was captured and they get another one when the KFT ticket is closed (and what the result was).  The other emails that are generated go to the users assigned to the queues responsible for handling the KFT ticket.  Some of these emails are on by default, others you might need to enable.  

The bottom line is that the KFT ticket contains all the information the user needs to address the feedback.  First, they are responsible for validating the feedback (ie: the link in Step 3 doesn't work anymore).  Then, they will update the article directly by Publishing a new version (if they agreed with the feedback).  Once that's done, they go back to the KFT ticket, fill in the "Close code" and "Close notes" with the action they took, and close the ticket.  We have our notifications configured so that the submitter's email contains both of those fields from the KFT, so we ask the KFT worker to be specific in the "Close notes" section.

[Eoghan Sinnott]

Is a KFT only created when a user submits a star rating or flags an article? I would be interested in using the KFTs but the majority of our feedback is left using the comments option. The last time I checked the KFTs weren't enabled for comments.

[Mike Van Vooren]

Yes, I believe it is configured to only trigger a KFT ticket on Star Ratings, Helpfulness responses, or Flag Article.  You set up the threshold you want for the Star Rating, so you only get tickets for low ratings (we have it set for 1 or 2 stars).  For Helpfulness, it only triggers a ticket for the "No" responses. 

We have hidden the "Comments" section for a variety of reasons.  Part of the reason is that the feedback left there would become inaccurate once the article was updated based on those comments.  Our content owners felt those outdated comments could be misleading and give a false sense of inaccuracy.

We have always gotten a great deal of feedback from the Star Ratings and Helpfulness question, so I think your users would find their way to those options as well if you chose to hide the Comments.