The fix for a revision-count argument is a visible running count both people can see, kept updated the moment a round closes rather than reconstructed from memory once the argument has already started. A short, shared log records the round number, the date it closed, and a one-line note of what was delivered. When a dispute happens later, you point to the log, not to memory or to tone. The log does not decide what counts as a round; it just answers, factually, which one you are on.
Why Memory Alone Fails by Round 3
By round 1, both sides remember clearly. By round 2, most people still agree, though the edges start to blur: was that clarifying email actually a small request, or nothing at all? By round 3, memory has usually split into two honest, incompatible versions of events.
This is not a trust problem. It is what memory does. A designer tracking a dozen details about a file remembers the work. A client tracking one project among many remembers the feeling of the last call more than its content. Neither side is lying when they disagree about the number; they are each reporting an honest reconstruction, and honest reconstructions drift apart at different rates.
The argument that follows is rarely really about the number. It is about which person's memory gets to be the default record. A log removes that question entirely, because the record was written down before anyone needed it to win an argument.
A Count Log Light Enough to Actually Keep
The reason most designers do not keep one is that "tracking system" sounds heavier than it needs to be. It needs four fields and nothing else.
| Field | What it captures |
|---|---|
| Round number | Which round this is, plain and sequential |
| Opened | The date the client's notes were received |
| Closed | The date the revised file was delivered back |
| Summary | One line: what changed |
That is the whole log. It can live in a plain document, a shared note, or a simple sheet, whatever you already keep project notes in; it does not need a dedicated system built for the purpose. The discipline that matters is not the format, it is that a row gets added the moment a round closes, not reconstructed weeks later when a dispute has already started. A log built retroactively is just memory with a header row.
Keep the summary line honest and specific rather than vague. "Adjusted per notes" tells you nothing three weeks from now. "Widened logo clear space, swapped body typeface, revised hero copy per email" tells you exactly what round 2 was, which matters if round 3 tries to reopen a decision that round 2 already settled. The same discipline that turns a vague note like "make it pop" into something actionable applies here: specific language now is what saves the argument later, a theme covered in decoding "make it pop" and other vague client feedback.
What to Say When the Count Is Disputed
When someone insists this is round 2 and the log says round 3, the instinct is to argue the point. Do not. Point to the record instead, in a tone that treats it as a shared reference rather than a scorecard.
Something close to this: "Good question, let me check the log. Round 1 closed on the 14th after the logo and color feedback. Round 2 closed on the 21st with the typeface and copy changes. This set of notes would be round 3."
Notice what that sentence does not do. It does not say "you're wrong." It does not reference memory at all, on either side. It reports dates and deliverables, which are facts nobody has a reason to dispute once they are stated plainly. Most disagreements end right there, because the client was not actually contesting the count, they were reporting a genuine uncertainty and are relieved to have it answered.
Confirming the Count in Writing at the Close of Every Round
The log only works as a shared reference if the client has actually seen it, which means the confirmation belongs at the end of every round, not saved for a project recap at the finish.
A short message the same day a round closes: "Sending over the updated file. This closes round 2 of 3, covering the typeface and copy changes from your last notes. Let me know if this looks good, and if there's anything further, that would begin round 3."
That last sentence is doing real work. It tells the client, plainly and without confrontation, exactly where the line sits before they cross it. A client who reads that sentence and still sends "one more thing" a week later is not confused about the count; they are making a request with full information, which is a very different conversation than the one where nobody said the number out loud.
When the Client Is at the Limit and Asks for One More
The count answers a factual question: which round is this. It does not answer what happens next, and it should not be stretched to try. When a client hits the agreed limit and asks for a further change, the log's job ends the moment it confirms the number.
What happens after that is a separate conversation, one about scope and cost rather than arithmetic. Resist the pull to have both conversations in the same breath, because mixing them turns a neutral fact into what feels like a refusal. "That would be round 4, past what we agreed" is accurate and cold. Splitting it in two works better: confirm the count plainly, then open a distinct conversation about whether and how to proceed, on its own terms. What that request usually signals, and how to recognize it before it becomes an argument at all, is covered in spotting scope creep before it costs you.
Where the Count Comes From in the First Place
A count log only has something to track because a round limit exists somewhere upstream of it, agreed at the proposal or kickoff stage before any file changed hands. The log does not set that number. It just keeps an honest, running tally against whatever number was already agreed.
The other piece the log depends on is a working definition of what actually starts and ends a round, since a log full of accurately dated but wrongly categorized entries is no better than no log at all. That definition, including the edge cases that cause most of the real arguments, a clarifying question, a same-round add-on, a request for a completely different direction, is covered separately in what a revision round actually is. Settle that first, then the count log has something reliable to count.
Both pieces sit inside the same discipline this site returns to repeatedly: agreements that live in writing outlast agreements that live in memory, a theme that runs through the whole solo design project process.
FAQ
How do you track design revision rounds?
Keep a short log with four fields: round number, the date notes came in, the date the revision went back, and a one-line summary of what changed. Update it the moment a round closes rather than reconstructing it later from memory.
What do you do when a client disputes the revision count?
Point to the log rather than to memory. State the dates and what was delivered in each round, plainly and without framing it as a correction. Most disputes are genuine uncertainty, not bad faith, and a factual answer usually settles them immediately.
Does a clarifying question count as a new revision round?
That depends on the definition agreed for what starts and ends a round, which is a separate question from counting mechanics. See what a revision round actually is for how to draw that line.
What happens when a client asks for one more change after the limit?
The log confirms the count, which is a factual answer. What happens next, whether the work continues and on what terms, is a separate conversation about scope, not something the count itself resolves.
Do I need special software to track revision rounds?
No. A plain document or a simple shared sheet is enough. The four fields matter more than the format, and the habit of updating it the moment a round closes matters more than either.