Since we’ve been anticipating the implementation of this FR for nearly two years, ever since it was filed and shared by the Document360 sales consultant assigned to us in May 2024, I’d like to add a bit more color on why this is so important.

Currently, Document360’s feedback submission feature isn’t intuitive or user-friendly. To understand why this matters, it helps to look at how customers typically interact with documentation. They visit the docs when they can’t find a feature or struggle to understand how to use it. In other words, when they’re already confused or frustrated.

If they still don’t find what they’re looking for, they either raise a support ticket or submit feedback that pinpoints to the section, paragraph, or sentence that needs improvement as part of current implementation. This kind of contextual feedback is extremely valuable because it helps us identify exactly where an issue exists and address it efficiently.

Unfortunately, the current “Give Feedback” option appears only at the end of an article and doesn’t capture any information about where the user faced a problem. We can’t expect customers to describe the navigation path or location themselves. For instance, if an article lists 20 different paths and a customer reports “the path doesn’t work,” there’s no way to know which one they’re referring to. That’s a poor experience and makes the feedback loop unnecessarily long and inefficient.

It’s not just external customers who face this limitation. our Customer Support and Sales teams also share feedback on published docs and often need to comment at the line or paragraph level. Other modern documentation tools, like ReadMe, already support a “suggest edit” feature that allows anyone to highlight text (similar to Google Docs) and leave a comment or suggest an edit. It’s intuitive, fast, and encourages meaningful engagement, and help close feedback faster.

What we’re looking for is a similar capability, a contextual, inline feedback system that allows users to comment directly on published docs. Even a simplified version that enables highlight-based feedback or inline commenting would make the process dramatically smoother for both users and writers. This approach would also align with how collaborative platforms like GitHub manage content edits in a very simple and structured way.

This is a really annoying issue, I agree. Together with the fact that editing an article blocks it from others, it renders quick collaboration impossible.