Internal Commenting/Suggestion Feature on Articles
Hi ZD team! We would like to see an internal commenting feature added to Zendesk guide articles. It would be something similar to Google Docs or Microsoft Word's ability to add comments to specific paragraphs, sentences, or words.
As a technical writing professional, this is a must-have. It's a huge hassle for our team when we are reviewing articles, as we can't do the reviews in the same place where we write and publish the article. Since Zendesk doesn't offer us any viable options for reviewing articles, we have to use Google Docs to fill in the gaps in this current workflow.
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.
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 !
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".
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.
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.
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.
Experiencing the same limitations here. Having to copy and paste from Google Docs due to not being able to view historical comments or mark up parts of an article natively within Zendesk adds additional time to our workflow and increases the possibility of human errors in the process. Can we please have a better reviewing feature built in Zendesk that supports the common content creation process of write > review > edit > review > publish
These sorts of limitations had us finally move authoring and managing content to Paligo and we publish directly into Zendesk and host the content there. We have full professional review, conditional text for when we publish the same article to different audiences, variables, and so on.
I need to have multiple versions of the same doc for internal and external audiences and I got tired of waiting. I needed a way to find and replace things like vendor names when they changed that didn't require manually touching hundreds of articles. I needed screen shots that could be reused.
Your milage may vary.
Sharon Burton We have almost the same use case and are also looking into Paligo to overcome this. Sounds like Paligo is serving you well and would serve us well too.
Thank you for all your comments, I just wanted to drop a quick update that we hear your need for more collaborative creation of Guide articles. We are in a process of upgrading the editor technology right now and once that's done it'll enable us to deliver on article commenting requests as well as other collaboration-related features.
Sharon Burton, I understand your frustration and I'm happy to hear that the Paligo integration works for you well. Just wanted to let you know that we have recently added image support for content blocks as well as an easy way to quickly replace images from the account-level gallery.
Vous devez vous connecter pour laisser un commentaire.