Quick answer: Good client feedback tracking for agencies means one feedback log per project, one owner who consolidates it, and a rule that feedback isn't actioned until it's in the log. Capture verbal feedback from calls the same day, resolve conflicting comments before they reach the designer, read the consolidated list back to the client, and close each round in writing.
Feedback rarely gets lost because somebody ignored it. It gets lost because it arrived in six places. The brand manager leaves comments on the PDF, the CEO says something offhand at the end of a call, the product lead replies to an email thread that half the team isn't on, and someone posts "one more small thing" in the shared Slack channel on a Friday evening. Every one of those is real feedback. Most agencies only have a process for the first one.
This post is about the plumbing: getting every comment into one place, deciding what to do when comments contradict each other, and proving to the client that you heard them. If you're more worried about clients adding work than about losing their notes, our piece on catching scope creep in client meetings is the better read.
Why does client feedback get lost at agencies?
Three reasons come up over and over.
- Verbal feedback has no home. Written comments leave a trail. A comment made on a call lives in whoever's head was paying attention, and if that was the account manager who then went on leave, it's gone.
- Nobody owns the consolidation. The designer gets the PDF comments, the strategist gets the email, the account lead gets the call. Everyone assumes someone else is merging it.
- Rounds never formally close. Without a clear "this is round two, and here's everything in it," late comments drift into the work whenever someone remembers them, and the client can't tell what was addressed.
The fix isn't a new tool. It's a habit with a few rules, and a log simple enough that people actually use it.
What does a good client feedback tracking log look like?
A spreadsheet or a board in whatever project tool you already use is fine. What matters is the columns. Mine has these:
- Date and source. "Call, 12 March" or "Email from Sam, 14 March." The source matters later when someone asks where an instruction came from.
- Who said it. Name and role. A comment from the CMO and a comment from an intern on the client side carry different weight, and you need to know which is which.
- The feedback, in their words where possible. Paraphrase is where meaning drifts. "Make the hero feel warmer" and "change the hero colour" are not the same request.
- Which deliverable and round. Homepage v2, round 2.
- Decision. Do it, push back, needs clarifying, or conflicts with item 14.
- Status. Open, in progress, done, or parked with a reason.
Keep one log per project, not per deliverable. Clients don't think in your deliverable structure, and a comment about tone on the landing page often applies to the emails too.
How do you capture feedback that's given on calls?
This is the gap in most agencies' client feedback tracking, and it's the one that causes the most arguments later. Written feedback can be scrolled back to. Spoken feedback becomes "but I told you on the call."
A few options, in order of effort:
- Assign a scribe. One person on your side whose only job on review calls is writing down feedback, with names. It works, but that person isn't contributing to the conversation.
- Recap at the end of the call. Spend the last five minutes reading back the feedback you heard. It catches misunderstandings while everyone's still there.
- Record the review call and pull the feedback from the transcript. You get exact wording and who said it, and nobody has to type while the client talks. Tell the client first; our guide to recording meetings with AI and getting consent covers what to say. If your client's IT team doesn't allow meeting bots, a desktop recorder or a browser extension captures the call from your own computer instead.
Whichever you choose, the feedback goes into the log the same day. Not the end of the week. By Friday, Tuesday's call has blurred into Wednesday's.
What do you do when stakeholders give conflicting feedback?
You'll get it on almost every project with more than two people on the client side. The marketing director wants the headline shorter; the founder wants it to explain the product. Both comments are in your log. Now what?
First, don't let the conflict reach the designer as two instructions. Their job is to solve the design problem, not to referee the client's internal disagreement. The Big Duck guide to consolidating feedback makes the same point: someone has to own the merge, and that someone flags conflicts instead of guessing.
Then do this:
- Agree up front who has the final say. Ideally at the client kickoff meeting. If you didn't, ask now. "When feedback conflicts, whose call is it?" is a perfectly normal question.
- Turn the conflict into one question. "Sam asked for a shorter headline, Priya asked for one that explains the product. Which matters more for this page: speed of reading or clarity for new visitors?"
- Send it to the decider, not the group. Group email threads about conflicts tend to produce a third opinion rather than a decision.
- Log the answer and who gave it. When the losing stakeholder asks why their comment wasn't done, you can point to the decision.
Ask for the problem, not the fix
A lot of conflicting feedback is two people proposing different solutions to the same problem. "Make the button red" and "move the button up" might both mean "people aren't seeing the button." Atlassian's advice on running design reviews includes consolidating feedback after the review and sorting it by priority, which is much easier once you know the problem behind each comment. Nielsen Norman Group has a short video on responding to unhelpful design feedback that's worth showing to junior designers who take every comment literally.
How do you show the client their feedback was heard?
Read it back. After each review round, send a short summary: here's everything we received, here's what we're doing with each item, here's what we need you to decide. Keep it scannable:
Round 2 feedback, homepage. 14 items received from calls, email and comments. 11 we're doing. 2 we'd suggest not doing, with reasons below. 1 needs a decision from you: headline length (Sam and Priya asked for different things). Next draft Thursday, once we have that answer.
This does two things. Clients see that the comment they made on a call in passing got written down, which builds a surprising amount of trust. And it gives them one chance to say "you missed something" before the work starts, rather than after.
The follow-up email is easy to automate a draft of; our guide to automating meeting follow-up emails shows how. Still read it before it goes. A wrong item in a feedback summary is worse than no summary.
How do you close a feedback round?
Put an end date on each round when you open it. "Please send all feedback on v2 by Wednesday at 5pm." Anything after that goes in the log as round three, unless it's a showstopper.
When the round closes:
- Every item in the log has a decision.
- Anything parked has a reason the client has seen.
- The client has the read-back summary.
- The team works from the log, not from the original emails.
That last rule matters more than it sounds. If designers go back to the raw email thread, they'll pick up the comment you agreed not to do.
Which client feedback tracking mistakes cost agencies the most?
- Acting on feedback that isn't in the log. The account manager mentions something in the corridor, the designer does it, and now nobody can trace why the page changed.
- Logging your interpretation instead of their words. You'll be asked "did I really say that?" Have the quote.
- Treating every stakeholder's comment as equal. It's polite and it's a recipe for a design by committee.
- Letting the log rot after launch. Old logs are useful. Six months later, when the client asks why the pricing page doesn't show annual prices, the answer is in there. The same idea scales up into a meeting knowledge base for the whole team.
Feedback is one kind of client commitment; the other kind is promises your team made. We cover those in AI meeting notes for consultants and agencies and in tracking customer promises.
A note on Acta
Acta records client calls with a bot or from your own computer and writes the transcript with speaker names, a summary and action items. OneChat lets you ask across past meetings, for example "what did the client say about the pricing page?", and answers with the sources it used. You can send the results to tools like Notion, Jira or Google Drive, where your feedback log probably lives already.
Frequently asked questions
What's the best tool for client feedback tracking?
The one your team already opens every day. A shared spreadsheet or a board in your project tool works as long as there's one log per project and one person owns it. The habit matters more than the software.
Who should own the feedback log at an agency?
Usually the account or project lead. They're on the calls, they know the stakeholders, and they're the right person to flag conflicts instead of passing them to the designer.
How many feedback rounds should a project have?
Agree it in the statement of work. Two or three rounds per deliverable is common, and an end date for each round matters as much as the count.
Should we record client review calls?
It helps, because you get exact wording and who said it. Always tell the client first and check the consent rules where they are.
What if a client gives feedback after the round closes?
Log it as the next round unless it's a real blocker. Tell them kindly where it's going and when it'll be handled.
See how call notes and action items come together on the Acta features page.
