Client feedback is part of the work. Extra work is not.
The difficulty is that the line between them is rarely announced clearly. A client does not usually say, ‘I would like to expand the scope now.’ They ask for another version, a new direction, one more page or a small addition that sounds close enough to the original job.
If every request is treated as a revision, the project can grow while the fee and deadline stay exactly where they started.
The useful question is not whether the client has given feedback. It is whether that feedback changes what was agreed.
Start with the original agreement
You cannot reliably identify new scope if the original scope is vague.
Before deciding whether a request is a revision, compare it with the agreement that priced the project. Look at the deliverables, quantities, revision rounds, creative direction, formats, responsibilities and deadline assumptions.
The boundary should come from the work that was agreed, not from whether the new request feels small.
What usually counts as a revision?
A revision normally improves or corrects a deliverable that already exists inside the agreed scope.
Examples might include:
- adjusting copy inside an agreed page;
- refining spacing, colour or hierarchy within an agreed design direction;
- correcting factual or technical errors;
- responding to feedback inside an included revision round;
- making reasonable refinements to the deliverable you already promised.
The exact definition depends on the agreement. Two projects can receive the same request and classify it differently because their original scopes were different.
What usually becomes new scope?
New scope changes the assumptions that the original price or schedule was built around.
Watch for feedback that:
- adds a new deliverable;
- adds another page, concept, format or variation;
- introduces a substantially different direction after one was already agreed;
- requires work from a new discipline or responsibility;
- arrives after the included revision rounds have been used;
- changes the timeline, dependencies or amount of work materially.
A request can take only thirty minutes and still be outside scope. Time is part of the impact, but it is not the definition.
Use a three-question test
When the boundary is unclear, run the request through three questions before doing the work.
1. Does it change the deliverable?
If the client is asking for something that was not part of the promised output, you are probably looking at new scope rather than a revision.
2. Does it change an assumption used to price the work?
More rounds, more formats, more stakeholders, a new direction or a faster deadline can all change the economics of the project even when the deliverable name stays the same.
3. Would you have quoted differently if you knew about it at the start?
This is often the clearest test.
If knowing about the request before the project began would have changed your fee, timeline or proposal, do not quietly hide it inside the word ‘revision’.
A revision can become new scope
The categories are not always fixed.
Changing a headline may be a normal revision. Rewriting the positioning for an entire website is different.
Adjusting an approved layout may be a revision. Asking for three completely new design directions after approval changes the job.
One included feedback round is a revision. A fourth round after the agreed limit may be additional work even if each individual edit looks familiar.
This is why revision limits alone are not enough. You also need a way to recognise when the nature of the work has changed.
Do not argue about the label
The goal is not to win a debate with the client about the meaning of ‘revision’.
Make the consequence visible instead.
A calm response can be:
That moves beyond the revision work we originally planned. I can add it — let me confirm the additional work and any impact on cost or timing before we continue.
This keeps the conversation about the project rather than the personalities involved.
Record the decision before the work starts
Once a request crosses the boundary, give it its own record.
At minimum, capture what changed, who requested it, the cost or time impact, the decision and the approval status.
That creates a clean separation between feedback that belongs inside the project and additional work the client has consciously chosen to add.
The rule worth keeping
Do not classify client feedback by how politely it is phrased or how quickly it could be done.
Compare it with the agreement.
If it improves what was already promised, it may be a revision.
If it changes what was promised, what the work requires or what you would have quoted, treat it as a scope decision before treating it as a task.
If you need the broader process around this boundary, start with how to handle client scope changes before they turn into unpaid work. Once a request is clearly outside scope, the next step is a defined client change request workflow before execution begins.