Internal Commenting/Suggestion Feature on Articles


  • Kalle Windefalk

    This is a must have in a KCS oriented organization. Now we need to connect a public article with an internal article if the resolution can't be achieved by the end-user. The article subjects will compete in the results when agent search for articles in the KC app. 

    If there was an internal section, the resolution for the help desk could be written in the public article and the reporting would be more correct. 


  • Nicolas Guyomar

    Hi ZD team,

    That "missing" feature is a major blocker for reviewer adoption in my opinion.

    A first step to ease the review process would at the very least to have the comment history accessible from the article, as we only retain the last one ? 

    Then what Katie explained would be perfect ! 

    Thank you

  • Dan Cooper
    Community Moderator

    Much of our support documentation is highly collaborative and we are still in an adoption phase with some portions of our team.  Having the review process restricted to one field without any history makes this process burdensome as we amp up the amount of articles needing review.  The suggestion to use commenting like Google Docs is a great one is that it's familiar to many users already who use Google, Microsoft, and Atlasssian products. 

    Even small changes here could gain large returns.  If the assignee field could show a history of what was said and by who, it would go along way in helping keep conversations in perspective until an article can be published.  It would also make sense to include in the Guide History events for the particular article.  

    Having one field without history quickly degrades the experience and an early question I'm hearing is "can another product do this better".

  • Shana Blackstone

    The suggestion Katie mentions is one of the reasons we are debating using another tool, such as Confluence, for our Knowledge Base. Internal comments and suggestions would do two things for us:

    1. Streamline the create/review process.

    2. Train internal customer support reps to give well-educated answers without extensive prior training. This would be game changing.

    The biggest miss I have seen with all documentation applications is not supporting customer-facing information and internal-only information in one single document. We use most of our documentation to train customer support reps. We have to maintain two documents. One for the customer, and another that is a copy of the customer-facing doc but with internal notes to educate the support teams as to the "why you would tell the customer this". The "why" is what makes for better customer support. And the "why" doesn't need to clutter up the customer docs.

    Neither Google nor Confluence, have this option. Everyone can see the comments. Unfortunately, two docs also mean eventually one gets updated, but the other does not. 

    This would put you leagues above other KB applications. Add versioning to that and I'd never think of using another product. 

  • Daniel Lautersztain

    As an org that has just moved our central KBs to Guide, we are also feeling the pain of lacking a robust comment feature-set that supports version history. I'd like to add that other than just internal commenting being paragraph/word specific, not having this for end users is also a pain. We are a feedback heavy company and encourage end users to leave feedback on articles but we wish this could be done by quoting specific sections. 

  • Jerry Lopez

    When an end user states that an article was not helpful, there is currently not a way to capture any additional feedback other than whether the article was helpful or not.  Therefore, it is hard to know what the end user had in mind that would make the article more useful.  Having a way to provide feedback would be quite helpful in improving the quality of our content.  


Please sign in to leave a comment.

Powered by Zendesk