When a Client Sends Conflicting Feedback From Multiple People (Get One Voice Without Picking Sides)
- Conflicting feedback from several people on the client side is not a design problem. It is a decision problem. If you try to satisfy every comment, you will build in circles and the project will run over without anyone being happy.
- Use the Profit Room's One Voice method: list every piece of feedback in one document, mark where the requests contradict each other or contradict what was already signed off, and ask the client to name one person who makes the final call. Build only what that person confirms in writing.
- Prevent it next time. Name the decision-maker in your agreement, route all feedback through them, and state that changes to already-approved work go through a change order. Then the conflict gets settled on their side, before it lands on your build.
The Short Answer
When a client sends conflicting feedback from multiple people, stop building and collect it. Put every comment in one place, note where requests contradict each other, and send it back to the client with one ask: who makes the final call on these? Then build only what that person confirms in writing. Say it plainly and helpfully: you want to build the right thing, and you need one clear answer so you do not build two versions of the same screen.
That is the One Voice method. It works because it moves the disagreement back to where it belongs - inside the client's team - without you having to tell anyone they are wrong. You are not picking sides. You are asking for a decision, which is a reasonable thing for any builder to need.
Why Feedback Starts Conflicting
It helps to know why it is happening, because the cause shapes how you word the reply.
- New people joined the review. The person who scoped the project brought in a partner, a manager, or a team that will actually use the build. They are seeing it for the first time and reacting to the whole thing, including decisions already made.
- Nobody agreed on the goal internally. The project was approved before the client's team settled what it was for, and now each person is pushing their own version.
- Different people use it differently. The owner cares about reports, the front desk cares about speed, and the sales lead cares about how it looks to customers. Each piece of feedback is honest. They just do not fit together.
- Your main contact is not the decision-maker. They passed your work up the chain and are now relaying several opinions they cannot settle. If your contact changed during the project, [when a client contact leaves mid-project](/blog/client-contact-leaves-mid-project) covers that case.
- Someone is reopening a closed decision. A feature you built exactly as approved is now being questioned by someone who was not in the room.
In nearly every case, nobody is acting in bad faith. Respond as if the team just needs help deciding, because that is usually what is going on.
Run One Voice
Reply the same day, in writing, before you change any code. Then follow these steps in order.
- Pause the affected work. Do not start building any of the conflicting requests. Building one person's version first makes it look like you have chosen a side.
- Consolidate everything. Put every comment into one short document or message, grouped by screen or feature, with who said what. Claude Code is useful here: paste the threads in and ask it to group the requests and flag where two of them cannot both be true. Read the result yourself before you send it.
- Mark the conflicts and the closed decisions. For each conflict, show the options side by side. For anything that changes work already approved, note the date it was signed off.
- Ask for one decision-maker. Ask the client to name the person who makes the final call, and to send back one confirmed list. If they named one in your agreement, point to it.
- Build only the confirmed list, and price what is new. Anything that changes approved work or adds scope goes through a [change order](/blog/change-order-template-for-a-claude-code-project) before you build it.
If They Will Not Name One Person
Some teams resist naming one decision-maker, or keep sending new opinions after the list is confirmed. You have a few reasonable options.
| Option | When it fits | What to watch |
|---|---|---|
| A short decision call with everyone | Several people disagree and email is going in circles | Send a written summary of the decisions right after and ask for a reply confirming it |
| Build to the signed scope only | New opinions contradict what was already approved | Point to the sign-off date; new requests become change orders |
| Offer paid design rounds | The team genuinely needs to explore options before deciding | Price each round and cap the number in writing |
| Pause until there is a decision | Work cannot move without an answer | Say how the pause affects the timeline, in writing |
Options when a client team will not settle on one voice
Whatever you choose, keep everything in writing and keep it friendly. If the conflict is really one person checking every detail, [dealing with a micromanaging client](/blog/deal-with-a-micromanaging-client) covers that pattern. If it is a stream of small changes, [handling client revision requests](/blog/handle-client-revision-requests) covers how to keep them inside the rounds you agreed.
Set It Up So It Does Not Happen Again
The easiest version of this conversation happens before the build starts. Add these to every project.
- Name the decision-maker in your agreement. One person who approves work and settles disagreements on the client side, plus a backup if they are away. [A one-page agreement before you build](/blog/one-page-agreement-before-you-build) shows where it fits.
- Route all feedback through that person. Ask the client to collect their team's comments and send one consolidated list per review round.
- Get sign-off at each milestone. Once something is approved, changing it is a change. [Getting a client to sign off on a build](/blog/get-a-client-to-sign-off-on-a-build) covers how to ask.
- Ask who else will see it, early. On the kickoff call, ask who will use the build and who might have opinions, and get them in the first review instead of the last. [Setting client expectations before a build](/blog/set-client-expectations-before-a-claude-code-build) covers that conversation.
- Send short weekly updates. A [weekly client update](/blog/weekly-client-update-prevents-fires) that the decision-maker forwards to their team keeps everyone seeing the same build, so fewer surprises show up at review time.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What should I do when different people at a client give me opposite feedback?
Pause the affected work, put every comment into one list with the conflicts marked, and ask the client to name one person who makes the final call. Build only the list that person confirms in writing.
Should I pick the best idea myself when client feedback conflicts?
No. Picking a winner puts you in the middle of the client's internal disagreement. Lay out the options clearly, give a recommendation if they ask for one, and let their decision-maker choose.
What if someone new wants to change work that was already approved?
Point to the date it was signed off and treat the request as a change. Price it with a change order and build it only once the decision-maker confirms it.
How do I stop a client team from sending conflicting feedback?
Name one decision-maker in your agreement, ask for one consolidated feedback list per review round, get sign-off at each milestone, and bring everyone who will have opinions into the first review instead of the last.
Should I build two versions so the client team can choose?
Usually not for free. Building both burns hours you are not paid for and still leaves the decision unmade. If the team genuinely needs to explore options, offer paid design rounds with a set number of rounds in writing.
Last reviewed October 15, 2026.
Co-founder of the Claude Code Profit Room. Built and sold AI services to real clients; writes about offers, pricing, outreach, and closing with receipts.
More from Duncan Rogoff →