When a client wants changes after delivery, the first thing to figure out is which kind of change they’re asking for. You send the final files. The client comes back with changes. This is one of the most common points of friction in freelance work, and the reason it causes so much trouble is that freelancers treat all post-delivery change requests the same way: either absorbing everything as free work or treating every request as an attack on the scope. Both responses are wrong, because not all post-delivery changes are the same thing.
Some of what clients ask for after delivery is legitimate feedback. Some is revision work covered by the contract. Some is new scope that wasn’t in the original brief. Each category has a different correct response, and knowing which you’re dealing with determines what you say next.
The Three Types of Changes a Client Wants After Delivery
Legitimate feedback means the work has a genuine problem, something that doesn’t match the agreed brief, a technical error, or a deliverable that missed its mark. This is not scope expansion. This is the work not being complete, and the response is to fix it without charging for it.
Revisions within scope means the work is correct but the client wants to refine it, and those revision rounds are included in the contract. This is expected. The response is to do the revisions, track the count, and know when you’ve reached the limit.
New scope means what the client is asking for wasn’t in the original brief, represents a different direction, or adds requirements that change the deliverable. This is not covered by the contract and is not free. The response is to name it and price it.
The mistake is treating all three as interchangeable. Absorbing new scope as if it were feedback costs you money and teaches the client that the scope is negotiable. Treating legitimate feedback as scope expansion costs you the relationship and makes you look like you can’t deliver. Treating revision rounds as free-for-all costs you both time and use. The taxonomy matters.
When the Work Has a Genuine Problem
If the feedback is pointing at something that doesn’t match the brief, a visual direction you agreed on that you missed, a specification you misread, something you delivered in the wrong format, that’s on you to fix. Do it cleanly and without defensiveness.
The professional response: “That’s helpful, let me look at this against the brief and get back to you with a plan.” Then check it against the brief. If the feedback is accurate, say so, address it, and deliver without making the client feel like they caught you doing something wrong. If you’re not sure whether the feedback is accurate, ask: “Can you point me to the part of the brief this is responding to?” That question is neutral and useful. It either clarifies the issue or reveals that the feedback is a preference, not a correction.
Clients who give feedback on work that matches the brief are often using “feedback” to mean “I’ve changed my mind”, which is a different situation entirely, covered below.
When You’re Within the Revision Rounds
If the revision rounds were defined in your contract and you haven’t exhausted them, do the revisions. That’s what the rounds are for. Track how many you’ve used and what each covered, not as a weapon, but as a record.
The moment you approach or reach the limit, name it proactively rather than waiting for the next round to arrive. “We’re coming up on the revision rounds included in the project, I want to make sure we use this last one well” is a more useful statement than “you’ve used all your revisions” after the fact.
If you didn’t define revision rounds in your contract, you’re in a harder position. You can’t reference a clause you didn’t write. What you can do is set a limit going forward: “I want to make sure we get this finished cleanly, I can accommodate one more round of consolidated feedback, and then I’d look to bring the project to final delivery.” That’s a new boundary, set in the moment, with a reasonable framing. It doesn’t fix the fact that it should have been in the contract, but it stops the open-ended revision loop from continuing indefinitely. Getting revision rounds into your contract before the project starts is the only clean solution to this problem.
When It’s New Scope
New scope looks like this: the client asks for something that wasn’t in the original brief, requests a different direction from what was agreed, or adds requirements that change what you’re producing. The test is simple, if you had known about this at the briefing stage, would you have priced the project differently? If yes, it’s new scope.
The framing matters. “That costs extra” reads as defensive. “That’s a different piece of work” reads as informational. The goal is to state the situation clearly without implying the client was trying to get something for free.
“Looking at what you’re describing, the direction has shifted from what we agreed in the brief. That’s a new scope of work. I can put together a short estimate for it if you’d like to go that way.”
That’s the full statement. You’ve named it, offered a path forward, and not made it an accusation. Most clients who didn’t intend to push scope will accept this readily, they just needed to be told. The ones who push back after a clear statement like that are in different territory.
If they dispute the charge, “but this is the same project”, the answer is to show them the brief: “I understand it feels like the same project. Let me share the original brief so we’re both looking at the same reference, and then you can see what shifted.” Put the original scope in front of them in writing. Setting this up clearly during onboarding is what makes the comparison possible and convincing.
When a Client Wants Changes After Delivery and Revision Rounds Are Exhausted
You’ve delivered the final work. The revision rounds are exhausted or never defined. The client wants more changes. This is the most common version of the problem.
The clean response is to price the additional work and offer it: “I want to make sure this is right for you. The additional round isn’t covered in the original project, I can put together a short note on what it would cost if you’d like to continue.”
Some clients will say yes. Some will decide the current version is actually fine. A few will push back. For the pushback: acknowledge the frustration without conceding the position. “I know this isn’t what you were expecting to hear. The revision rounds we agreed on covered the work we’ve done, for anything beyond that, it’s additional time I need to price separately.” Repeat once. If they continue to push, you have a decision to make about the relationship, not the invoice.
How the client responded during the project is the best predictor of how they’ll respond at this stage. A client who was collaborative throughout and is now asking for a genuinely small extra thing is different from a client who has been testing limits since the kickoff.
What Prevents This Next Time
The revision clause in your contract is the first fix. It needs to specify the number of rounds, what counts as a round, how feedback is to be submitted, and what happens when rounds are exhausted. A clause that says “two revision rounds are included” without defining those terms still leaves room for dispute.
The brief confirmation is the second fix. Getting written client sign-off on the brief before work starts means that any post-delivery request for “something different from what I described” has a clear reference point. Setting this up as part of client expectations before work begins is what makes the conversation factual rather than interpretive.
The third fix is defining “done” before you start. What does final approval look like? An email confirmation? A specific phrase? What happens if the client doesn’t respond? This sounds bureaucratic until you’ve delivered final files and received three weeks of silence followed by “actually, I have some changes.”
Post-delivery change requests will happen regardless of how well you set up a project. The difference is whether you handle them from a position of clarity or from a position of ambiguity. Clarity is almost always faster, cheaper, and better for the relationship.
