I maintain Comments Exporter, which helps turn supported comment threads into CSV or XLSX files. For a review session, I would treat that export as the source material for a separate decision log. The point of the log is to connect observations with actions while keeping the original comments available for checking.
Begin with a question the review can answer
“Understand the audience” is too broad to guide a short review. A more useful question might be, “Which setup instructions are readers asking us to clarify?” It gives reviewers a reason to distinguish a request for help from a general reaction to the post.Write that question above the working notes. If the team later encounters pricing complaints or unrelated suggestions, keep them visible but avoid silently changing the purpose of the review. They may deserve their own pass. One export can support several investigations without forcing every row into the same conclusion.
Preserve the original words beside your interpretation
Keep the downloaded file intact and use a working copy for labels. Add a small set of columns for the review question, the proposed action, and the evidence behind it. These are analyst-added fields, not information the commenter supplied. Making that distinction visible prevents a later reader from mistaking an internal label for an original statement.For example, a row labelled “instructions unclear” should retain the specific comment that motivated the label. If the comment simply asks where a button is, the team should not silently convert that into “the feature is broken.” Both interpretations could lead to work, but they describe different problems and need different evidence.
Use the source thread when context matters
A comments exporter makes material easier to sort and review, but a file is still a capture of available data. The product's documentation discusses file formats and data availability; it does not make every conversational relationship self-explanatory once rows are separated from the page.When a message depends on a preceding exchange, return to the source thread if it remains available. A brief reply such as “that worked” is difficult to interpret without knowing what suggestion it answered. If the necessary context cannot be recovered, mark the interpretation as uncertain rather than inventing the missing exchange.
Keep action and priority separate
A suggested action can be clear even when its priority is undecided. “Add a screenshot showing the settings button” describes a possible response. “Urgent” requires a separate judgment about impact and the team's current responsibilities. Combining those two decisions in one label makes the review harder to revisit.Record who will consider the action and what would resolve it. That could be a documentation change, a support response, or a closer inspection of the original discussion. An exported row should not automatically become a task merely because it contains a negative word.
Leave a trail for the next reviewer
At the end of the session, preserve the review question, the source reference, and the meaning of the labels you used. List unresolved interpretations as unresolved. Another person should be able to follow a proposed change back to the relevant comment and see where human judgment entered the process.The result is more useful than a collection of sentiment labels alone: it explains what the team noticed, what it proposes to do, and what still needs checking before anyone acts.