When a Client Changes Their Mind After Approving Work (Without Eating the Cost)
- A client changing their mind after they approved something is normal. They saw the real thing, used it, or showed it to someone, and now they want it different. The problem is not the change. The problem is treating it as a revision you owe them instead of new work.
- Use the Profit Room's Approval Line method: confirm the approval in writing, separate a real defect from a new preference, price and date the change before you touch it, and let the client choose. Fix genuine bugs for free. Charge for changed minds.
- Prevent it next time. Make approvals specific and written, say in your agreement what an approval means, show work early so changes happen before sign-off, and keep a change-order process ready.
The Short Answer
When a client changes their mind after approving work, treat the approval as a line. Work before the approval was part of the agreed scope. A change after it is a new request. Acknowledge it warmly, confirm what was approved and when, then send a short change order with the price and the effect on the timeline. The client decides whether the change is worth it. You build it once they say yes.
That is the Approval Line method. It works because it removes the argument. You are not saying no, and you are not saying they made a mistake. You are saying the change is possible and here is what it costs, the same way any professional would. Most clients accept that, and the ones who push back usually do it because nobody told them up front what an approval meant.
Why Clients Change Their Minds
Knowing the reason helps you pick the right response.
- They saw it working. A mockup or a description is not the same as using the real thing. Once the client clicks through it, they notice what they actually want.
- Someone else saw it. A partner, a manager, or a key customer gave an opinion after the contact signed off. [When a client sends conflicting feedback from multiple people](/blog/client-sends-conflicting-feedback-from-multiple-people) covers how to handle that.
- Their business changed. A new offer, a new process, or a new priority makes the approved version less useful than it was.
- The approval was rushed. They said 'looks good' without really reviewing, because the review was too big or came at a busy time. [When a client takes forever to give feedback](/blog/client-takes-forever-to-give-feedback) covers how to make reviews easier to do properly.
- It is actually a bug. Sometimes what sounds like a change of mind is the build not doing what was agreed. That is on you, and it is free.
Only the last one is your cost to absorb. The rest are normal, healthy changes that deserve a fair price, not resentment.
Run the Approval Line
Use these steps every time an approved piece of work comes back with a change.
- Acknowledge the request without agreeing to the work. Thank them, say you understand what they want, and say you will come back with what it involves. Do not start building in the same reply.
- Find the approval. Pull up the message, the sign-off, or the meeting note where they approved it. If the approval is vague, that is useful information about your process, but it is still the record.
- Sort defect from preference. Check the request against what was agreed in the scope. If the build does not do what was agreed, it is a defect: fix it free and quickly. If it does what was agreed and they now want something else, it is a change.
- Price and date the change. Estimate the work, including anything already built that has to be undone or retested. Claude Code can help you trace what the change touches across the project, but you decide the scope and the price. Write it up using a [change order template](/blog/change-order-template-for-a-claude-code-project).
- Let the client choose. Send the change order with options: do it now at the stated price and date, schedule it for after launch, or keep the approved version. Then build only what they confirm in writing.
Defect or Change: How to Tell
This is where most of the friction lives, so be honest with yourself about which side a request is on.
| Request | Defect or change | What to do |
|---|---|---|
| It does not work the way the scope described | Defect | Fix it for free, and say so |
| It works as agreed, but they want a different layout or flow | Change | Send a change order |
| A new person wants it done differently | Change | Change order, and confirm who has final say |
| Their business process changed after sign-off | Change | Change order, often a good candidate for after launch |
| The scope was unclear on this point | Gray area | Do a small fix as goodwill, and tighten the scope wording next time |
Sorting a post-approval request
Keep the undo cheap on your side. Commit approved work as its own clear point in version control, and keep the approved version reachable, so a change can be built and compared without losing what was signed off. [Claude Code checkpoints for client work](/blog/claude-code-checkpoints-for-client-work) covers the safety net inside a session.
Set Up Approvals That Hold
The best protection is an approval process the client understands before the first review.
- Define approval in your agreement. Say what signing off on a milestone means and that changes after it are handled as change requests. [A one-page agreement before you build](/blog/one-page-agreement-before-you-build) shows where that fits.
- Make approvals specific. Ask the client to approve a named thing, such as 'the booking flow as shown in this video', not 'the project so far'. [Getting a client to sign off on a build](/blog/get-a-client-to-sign-off-on-a-build) covers the wording.
- Get it in writing. A short reply to an email that lists what is being approved is enough. A thumbs-up on a call is not.
- Show work early. Share rough versions so the client changes their mind before approval, when it is cheap, instead of after.
- Include a revision round. One round of changes before approval is part of the price, the way [handling client revision requests](/blog/handle-client-revision-requests) lays out. After approval, the change order takes over.
- Tie payment to delivered milestones. [Structuring client payments around milestones](/blog/structure-client-payments-milestones) keeps a late change from also holding up money you already earned.
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 changes their mind after approving work?
Acknowledge the request, confirm what was approved and when, and check whether it is a defect or a new preference. Fix defects for free. For changes, send a short change order with the price and the effect on the timeline, and build only once the client confirms in writing.
Should I charge a client for changes after they approved the work?
Yes, if the work does what was agreed and the client now wants something different. That is new work. If the build does not match the agreed scope, it is a defect and you fix it at no charge.
How do I tell a client a change will cost extra without upsetting them?
Stay warm and factual. Say you understand the request, point to the approval, explain what the change touches, and give options: do it now at a stated price, add it after launch, or keep the approved version. Let them choose.
What if the client says they never really approved it?
Share the written approval calmly. If there is no clear written record, treat it as a gray area, consider a small fix as goodwill, and make approvals specific and written on every project from now on.
How do I stop clients from changing their minds after approval?
Define what approval means in your agreement, ask clients to approve specific named pieces in writing, show rough versions early so changes happen before sign-off, include one revision round, and keep a change order process ready for anything after.
Last reviewed October 19, 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 →