Round two of feedback comes in, and a few comments later someone asks "wait, did we already fix this?" Nobody's sure. The screenshot in the client's email is from a draft two versions old, half the notes in the thread reference a layout that's already gone, and now someone has to spend twenty minutes reconstructing a timeline that should have been obvious from the start.

This is the quiet cost of feedback without version history: not any single lost comment, but the growing tax of figuring out, every round, what's actually still open.

Why "just scroll up the email thread" stops working

Email and chat threads record feedback in the order it arrived, not in the order the design changed. By round three, a thread mixes notes about three different versions of the homepage with no visual marker for which version each comment belonged to. Reconstructing that mapping from memory is exactly the kind of work a review tool should be doing automatically instead of leaving to whoever's paying closest attention.

Tie each comment to the version it was left on

The fix isn't a better list, it's keeping each comment attached to the specific version of the page or file it was made against. When a client says "move this button," that note should stay pinned to the version where that button existed in that position, even after three more versions ship. Roundmark keeps version screens for exactly this reason, so an old comment doesn't get stranded, pointing at a layout that no longer exists, when a client opens a project to check on something weeks later.

Close the loop explicitly, every round

A comment that gets addressed should say so, not just disappear when the next draft goes up. Mark it resolved, and resolve it against the version where the fix actually landed. This matters more than it sounds: a client scanning a project months later should be able to tell, at a glance, whether an old note was fixed, dropped, or just forgotten, without messaging you to ask.

Keep a short running summary, not just raw comments

Raw comment threads answer "what was said." They don't answer "what actually changed," which is the question a client, or a new team member joining mid-project, actually has. After each round, write three or four lines: what changed, what's still pending, what got pushed to a later round. This takes minutes and saves the alternative, someone scrolling through every comment on every version to reconstruct the same summary from scratch.

Make the history visible to the client too, not just your team

Clients forget what they asked for almost as fast as agencies forget what they fixed. A client-visible version history, where they can see earlier drafts alongside the comments that were left on each one, heads off the "I don't think we ever addressed this" conversation before it starts. It's also the fastest way to answer a client who asks why something changed: point to the exact version and the exact comment that caused it.

A simple naming habit that pays off later

Even with a tool handling version history automatically, a short naming habit helps: refer to drafts by round number in conversation, "the round two homepage," rather than by date or file name. Clients remember "round two" far more reliably than "the version from the fourteenth," and it keeps everyone talking about the same draft without needing to open the tool just to confirm which one is meant.

Don't let "final" versions multiply quietly

A subtle version-tracking failure: a file named "final" gets a small tweak and becomes a second, different "final," with no comment history carried over because nobody treated it as a new version. Any time a page changes after a round is marked complete, even a small fix, treat it as a new version with its own record, rather than letting the old file name imply nothing changed when something did.

Where Roundmark fits

Every version of a reviewed page or file stays in Roundmark with its own comments attached, so a note from round one stays readable in its original context even after round four ships. Pair that with the revision-round structure you've already agreed with the client, and tracking what changed between rounds stops being a reconstruction job. Start free to see it on your next project.

FAQ

How do you track what changed between feedback rounds?

Keep each comment tied to the specific version of the page or file it was left on, and write a short summary after every round covering what changed, what's pending, and what moved to a later round.

Why do old comments get confusing after a few revision rounds?

Because email and chat threads list comments by arrival time, not by which version of the design they refer to. Once a layout changes, an old comment without a version attached points at something that no longer exists.