When a Client Takes Forever to Give Feedback (Keep the Project Moving)
- A client who takes weeks to review your work is rarely ignoring you. They are busy, the review feels big and vague, and nothing tells them it is blocking anything. Every quiet week pushes your launch date and eats time you planned for other clients.
- Use the Profit Room's Review Clock method: make every review small and specific, give it a due date the client agreed to, show what the delay moves, and follow a written rule for what happens when the date passes. Do not keep building on unapproved work, and do not quietly absorb the lost time.
- Prevent it next time. Put review windows and a pause rule in your agreement, tie payments to milestones instead of approvals, and book review calls instead of waiting for emails.
The Short Answer
When a client takes forever to give feedback, stop sending bigger and longer reminders. Make the review easier to do. Ask for feedback on one specific thing, with two or three clear questions, a due date the client agreed to, and a short note about what the delay moves. If the date passes, follow the rule you agreed at the start: the project pauses, the launch date moves by the same amount, or the work is treated as approved after a set window.
That is the Review Clock method. It works because slow feedback is almost never about you. It is about a review that feels like homework with no deadline. When you shrink the task and put a clock on it, most clients answer on time, and the ones who do not have already agreed to what happens next.
Why Clients Sit on Reviews
The reason shapes the fix, so work out which one you are dealing with.
- The review is too big. 'Take a look and let me know what you think' about a whole app feels like a project. People put off tasks they cannot finish in one sitting.
- They do not know what you need. Without specific questions, they do not know whether you want a full test, a gut reaction, or a yes.
- Nothing shows it is blocking. If the client thinks you are still building in the meantime, a slow reply feels harmless.
- Someone else has to weigh in. The contact may be waiting on a manager or a partner. [When a client sends conflicting feedback from multiple people](/blog/client-sends-conflicting-feedback-from-multiple-people) covers that version.
- They are unsure about the project itself. Sometimes slow feedback is a sign of second thoughts. If replies have stopped entirely, [what to do when a client goes silent](/blog/what-to-do-when-a-client-goes-silent) is the better guide.
In most cases the client still wants the project. They just have a full week, and your review is the task with no clear end and no clear deadline. Fix that and the problem usually shrinks.
Run the Review Clock
Use these steps on the next review, and on every review after it.
- Shrink the review. Send one piece at a time, not the whole build. A short screen recording or a link straight to the page or flow you need checked beats a long email. Claude Code can help you draft a clear summary of what changed since the last review, but you decide what goes in front of the client.
- Ask specific questions. Two or three, such as 'Does this booking flow match how your team takes appointments?' and 'Is this the right wording for the confirmation message?' Specific questions get specific answers.
- Agree on a due date. Ask when they can review it and hold them to their own date. A date the client picked is easier to keep than one you set.
- Show what the delay moves. In a calm sentence, say what the review unblocks and how the launch date shifts if it slips. Put it in your [weekly client update](/blog/weekly-client-update-prevents-fires) so it is visible every week.
- Follow the rule when the date passes. Send one friendly reminder. If the date still passes, apply what your agreement says, in writing, and say what you are doing next. Then move to other client work instead of waiting.
What to Do While You Wait
Waiting on feedback is where most builders lose money without noticing. Be clear about what you will and will not do in the gap.
| Situation | What to do | Why |
|---|---|---|
| The next step depends on the unreviewed work | Pause that step and say so in writing | Building on unapproved work means paying twice if it changes |
| Other parts are independent of the review | Keep building those | The project keeps moving without risk |
| The review date has passed once | One friendly reminder plus an offer of a short call | A call often gets in ten minutes what email cannot get in a week |
| The date has passed again | Apply the pause or launch-date rule from your agreement | The rule is agreed, so it is not personal |
| The delay is pushing into time booked for other clients | Reschedule the remaining work to your next open slot | Your calendar is not on hold for one client |
Handling the wait on a slow review
If slow reviews keep pushing the final payment back, the problem is how your payments are tied to approvals. [Structuring client payments around milestones](/blog/structure-client-payments-milestones) and [getting a client to sign off on a build](/blog/get-a-client-to-sign-off-on-a-build) cover how to keep your cash flow from depending on someone's inbox.
Set It Up So It Does Not Happen Again
The best time to solve slow feedback is before the first review. Add these to every project.
- Write review windows into your agreement. Say how long the client has to review each milestone and what happens if the window passes. [A one-page agreement before you build](/blog/one-page-agreement-before-you-build) shows where that fits.
- Add a pause rule. If feedback is late by more than the agreed window, the project pauses and the timeline moves by the same amount. Clients rarely mind a rule they agreed to at the start.
- Name one reviewer. Agree on who gives final feedback for each milestone, so you are not waiting on a group.
- Book review calls up front. Put short review calls on the calendar at kickoff, matched to your milestones. A meeting on the calendar beats an email in the inbox.
- Tie payments to delivery, not approval. Invoice when the milestone is delivered for review, so a slow review does not also mean a slow payment. Limit rounds of changes the way [handling client revision requests](/blog/handle-client-revision-requests) lays out.
Short, practical drops on offers, outreach, pricing, and closing clients with Claude Code. No spam, unsubscribe anytime.
Frequently asked
What should I do when a client takes forever to give feedback?
Make the review small and specific, ask two or three clear questions, agree on a due date with the client, and show what the delay moves. If the date passes, send one reminder, then apply the pause or launch-date rule from your agreement.
Should I keep building while waiting for client feedback?
Only on parts that do not depend on the work being reviewed. Building on top of unapproved work means redoing it if the client asks for changes, so pause those steps and say so in writing.
Can I treat no response as approval?
Only if your agreement says so. If it does, remind the client of the rule before the review window closes. If it does not, do not assume approval, and add the rule to your next agreement.
How do I remind a client about feedback without being pushy?
Keep it short and specific. Name the one thing you need, link straight to it, list your questions, and offer a quick call as an easier option. Mention what the delay moves in a calm sentence, without blame.
How do I stop slow feedback on future projects?
Put review windows and a pause rule in your agreement, name one reviewer per milestone, book review calls at kickoff, and invoice when a milestone is delivered rather than when it is approved.
Last reviewed October 18, 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 →