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.
Six requests: check the baseline before the label
Fictional agreement: five named website pages, website deliverables only and two revision rounds within one design direction. The examples show operational decisions; your actual agreement determines the boundary.
| Request | Agreement check | Classification | Next action |
|---|---|---|---|
| Shorten headline | Copy edits included; round 1 of 2 | Revision | Revise within the agreed page |
| Fix incorrect phone number | Supplier entered the wrong supplied number | Correction | Correct; verify against source |
| Add a sixth page | Five named pages agreed | New deliverable | Estimate and seek decision |
| Provide square social assets | Website files only | New format | Confirm quantity and fee |
| Third feedback round | Two rounds used | Additional round | Assess changes and agree impact |
| Change colour palette | Direction still under review | Clarify | Check whether this refines or replaces the direction |
Check the included round, direction and responsibilities. A correction of your own error needs its own assessment.
Estimate the added deliverable, format or round. Confirm fee and timing before creating production work.
Test the distinction: change the baseline so square social assets are explicitly included. The same request now sits within the promised output. The request did not change; the agreement did.
Keep the request and its source in a feedback log. Record the agreed outcome using the scope change log and preserve approval of the exact change.
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.
Frequently asked questions
Is a correction the same as a paid revision?
Keep corrections distinct from new requests. Check the original requirements and who introduced the error before deciding how to handle it; a used-up revision allowance does not by itself explain responsibility for an error.
Does a quick change automatically count as included?
No. Effort helps you assess impact, but the agreement defines the output. A short additional format can still require a scope decision.
Can a request within a revision round still be new scope?
Yes. An included round does not automatically cover a new page, concept or discipline. Check both the round allowance and the nature of the requested work.
What should I do if the original scope is vague?
Identify the unclear deliverable or assumption, discuss it with the client and record the agreed boundary before proceeding. Do not treat your own interpretation as a confirmed decision.
For ways to respond without rejecting every request, use the scope-creep guide.
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.