A Simple System for Client Feedback Rounds
Endless revision rounds kill timelines and budgets. You share a design, feedback arrives in five different WhatsApp messages from three different people, half of it contradicts the other half, and two weeks later you are still on “version 7 final final”.
Over the years I have settled on a simple feedback system that keeps projects moving and keeps everyone clear on what happens next. It is not complicated. It just has to be agreed before the first draft goes out.
1. One decision-maker, agreed up front
Before any work starts, I ask the client to name one person who gives final approval. Other people can contribute, but their input goes through that person.
This one rule removes most feedback chaos. It stops the situation where the marketing lead approves a direction and the managing director overturns it a week later. If several people must be involved, the decision-maker collects and consolidates their comments before sending them.
2. One channel for feedback
Feedback that is scattered across WhatsApp, email, phone calls and voice notes gets lost. I agree a single channel for formal feedback, usually a shared document or comments directly on the design or staging site.
WhatsApp is fine for quick questions. It is not where changes get approved.
3. A fixed number of rounds, written into the proposal
Every proposal states how many revision rounds are included at each stage. Typically that is two rounds on design and one round on the built site before launch.
A round means: the client reviews the whole thing, sends consolidated feedback in one go, I make the changes, and we move on. Ten separate emails over a week are not ten rounds. They are one round that has not been consolidated yet.
When the rounds are written down, everyone takes each one more seriously. Clients review properly the first time because they know it counts.
4. Feedback on problems, not solutions
I ask clients to describe the problem rather than prescribe the fix. “The pricing section feels hard to compare” is more useful than “make the boxes blue”. The first lets me solve the actual problem. The second often fixes a symptom and creates a new issue somewhere else.
To help with this, I share a short set of review questions with each draft:
- Does this communicate what your business does within a few seconds?
- Is anything missing that a customer would need to make a decision?
- Is anything inaccurate or out of date?
- Does anything feel off-brand?
5. A clear line between feedback and new requests
This is where most scope creep happens. Feedback is about changing what was agreed. A new request is something that was not in the original scope: a new page, a new feature, a new integration.
When something new comes up, I say so clearly and kindly: “That’s a great idea. It’s outside the current scope, so I’ll send a quick quote, or we can add it to phase two.” Most clients appreciate the clarity. The ones who push back usually needed the conversation anyway.
6. Set response times on both sides
I commit to turning around consolidated feedback within an agreed number of working days. I ask the client to do the same for reviews. If a review sits for weeks, the timeline moves, and that is in the proposal too.
This keeps momentum, and it makes it clear that delays are shared responsibility, not just the developer’s problem.
7. A clean handover, not endless support
The project ends with a proper handover: a written or recorded guide showing how to update the site, and if needed, one focused virtual training session. Anything after that falls under a maintenance retainer.
Ending cleanly matters. Without it, “small changes” continue indefinitely after launch, unpaid and unplanned.
Why this works
None of these rules are about being difficult. They protect the client’s budget and timeline as much as mine. A project with clear feedback rules finishes faster, costs what was agreed, and ends with both sides happy to work together again.
If you are planning a project and want a clear, structured process from day one, let’s talk.