Managing Client Feedback and Revisions at an Agency

One of the places an agency burns the most energy is the revision process — not because the work is bad, but because feedback is scattered. In this article we build a practical approach that keeps order while collecting client feedback and managing revisions. The goal is not to eliminate revisions — that is impossible — but to make them traceable and bounded.

Why does feedback scatter?

Feedback scatters because the client writes the moment it comes to mind, through whatever channel is easiest. One comment is said in a meeting, another arrives by chat, a third is attached to an email. None of them is wrong, but none sits next to the work. As a result the team spends time gathering feedback before it can act on it.

The problems with chat and email revisions

• Lost context: "the text there is off" does not say which file, which version.
• Version confusion: a comment about v2 arrives after the team has moved to v3.
• No record: verbal approvals live nowhere; in a dispute nobody remembers what was said.
• Scattered ownership: three people comment on the same thing, and which one is authoritative is unclear.

Tie feedback to a specific file or delivery

The first rule of good revision management is simple: every comment should live next to the work it is about. A comment "about the second version of the homepage design" that is attached to that delivery means the team never has to guess which file it refers to. Tying feedback to its context is the single most effective change to shorten revision time.

Name a single decision-maker

The most common cause of conflicting feedback is multiple people commenting at once without coordination. The marketing lead wants one thing, the CEO another, and the agency is caught in between. The fix is to name one person on the client side who collects feedback in a single place. Having them combine internal views and send one clarified comment makes everyone’s job easier.

Define a revision round

The answer to "when does revision end?" is revision rounds defined up front. A round is applying collected feedback as one package. Instead of one-off comments dripping in, saying "in this round we collect these, apply them, then move to the next round" disciplines both the team and the client.

1. (01)

   Open the round

   Share the delivery and set a clear window for feedback.

2. (02)

   Collect the feedback

   Gather all comments in one round, next to the relevant delivery.

3. (03)

   Apply and close

   Apply the collected comments, close the round, and share the new version.

Manage comments as open, resolved and reopened

Every comment should have a state: open, resolved, or reopened. This simple distinction removes the "did we fix that?" question. If a resolved comment can be reopened by the client, the team sees at a glance which issues are still contested. Stateless comments hang in the air forever.

Preserve file versions

When a new version is uploaded and the old one disappears, the revision history goes with it. When someone says "the previous version was better," you need to be able to go back to it. Preserving versions protects the team and answers "which change did we make when?"

Separate approval from revision

Approval and revision are different decisions and should not be mixed. "Looks nice" is not approval; approval is a clear signal that the work can move to the next stage. When deliveries have a distinct "approve" versus "request revision," the team does not have to guess what is done and what is still open. The same separation applies to formal decisions like proposal approval and contract signature.

Clarify vague client comments

Comments like "something is missing" or "make it a bit livelier" are not actionable. Accepting them as-is and guessing usually leads to the wrong revision. The right reflex is a short clarifying question: "By livelier, do you mean color or layout?" That one question saves a wasted round.

Handling requests outside the revision scope

Some requests are not revisions but new work. "Let’s also add this page" looks like a revision but expands the scope. You have to separate these gently but clearly. You do not have to reject an out-of-scope request; positioning it as a separate item both protects the relationship and prevents unlimited revisions.

A sample revision flow

The flow below is a plain example of a repeatable revision process. Adapt the number of rounds and the steps to your service type.

1. (01)The delivery is shared in its project context and a revision round is opened.
2. (02)The client-side owner collects internal views and sends one clarified batch of feedback.
3. (03)Vague comments are clarified with short questions before being applied.
4. (04)Out-of-scope requests are marked as separate items.
5. (05)Comments are applied, each marked "resolved," and the new version is shared.
6. (06)The client approves or reopens the remaining points; the round closes.

Cowwwork’s context-bound comments

Everything above shares one principle: feedback should live next to the work it belongs to. Cowwwork ties comments to a specific delivery or file, preserves versions, and offers a clear approve-versus-revision decision on deliveries, so the "which version, which comment?" confusion disappears. See how the file and feedback flow keeps everything in one place.