Revision or change request? A decision table
Ten rows and eight worked examples for classifying client requests before you start the work.
The hardest part of scope management is not writing the contract. It is the twenty seconds after a client email lands, when you have to decide whether the request is included work or new work, and you do not want to seem difficult.
This article gives you a decision test you can apply in those twenty seconds, a table you can keep next to your inbox, and eight realistic requests classified with the reasoning shown.
The two definitions, kept apart
A revision refines an already approved deliverable, within the direction and specification you both agreed to. The work changes. The definition of the work does not.
A change request modifies the agreed definition: the scope, the deliverable list, the direction, the platform, the timeline, or the quality bar. In project management terms this is a formal proposal to modify something under change control, and change control itself is defined as the process by which modifications to documents, deliverables, or baselines are identified, documented, approved, or rejected (PMI Lexicon of Project Management Terms).
The design industry has its own name for the same artifact. The AIGA Standard Form of Agreement describes a change order as "a document drafted by the designer to acknowledge a client request that is outside of the original scope for the project," in which "the designer describes the amount of additional time and money required and sends the change order to the client for review and an authorized signature" (AIGA Standard Form of Agreement for Design Services).
Note what a change request is not. It is not a refusal. It is a small written proposal that keeps the request alive while pricing it honestly. Upwork's guidance identifies the absence of exactly this mechanism as a primary cause of uncompensated work: without a formal process for handling scope changes, freelancers often feel pressured to accommodate additional requests to maintain the relationship (Upwork).
The three question test
Run each request through these in order.
1. Does it change what was approved, or how well it was executed? Execution quality inside an approved direction is a revision. A change to the approved direction is a change request.
2. Does it add a deliverable, a size, a format, a platform, or a round that is not on the scope list? If yes, it is a change request regardless of how small the effort is. Effort is not the test. The deliverable list is the test.
3. Can you name where it sits in your written scope? If you can point to the line, it is a revision. If you cannot, it is either a change request or a clarification. When in doubt between those two, ask one clarifying question before quoting. Many apparently out of scope requests turn out to be misworded in scope requests, and quoting first makes you look transactional.
There is a fourth category worth naming: the courtesy fix. Typos, misspelled names, a file exported at the wrong bitrate on your end. Do those immediately and do not count them against a round. Errors you introduced are always yours to fix.
Decision table
| Signal in the request | Classification | Why | What you send |
|---|---|---|---|
| Refines an approved element: spacing, color within palette, trim timing, copy tightening | Included revision | Same direction, same deliverable | Updated draft, logged to the round |
| Vague reaction with no location: "not quite there," "make it pop" | Clarification needed | Not yet actionable | One clarifying question, round not started |
| Contradicts earlier approved feedback | Clarification needed | Confirm which decision stands | Restate both, ask which wins |
| Returns to a direction you already ruled out together | Change request | Reopens an approval gate | Short quote, cost and timeline |
| Adds a deliverable, size, format, or platform | Change request | New item, not on scope list | Short quote, itemized |
| Adds a new stakeholder with fresh opinions late in the project | Change request, usually | Adds a review cycle not scoped | Extra round quoted, or consolidate |
| Changes the strategy, audience, or message | Change request | Changes the brief itself | Quote, possibly a new scope record |
| Third or fourth batch after included rounds are used | Change request | Rounds are the scoped unit | Additional round at stated rate |
| Fixes an error you made | Courtesy fix | Your defect | Fixed copy, no round consumed |
| Fixes a typo or wrong detail the client supplied | Courtesy fix, up to a point | Cheap goodwill, but log volume | Fixed copy, note the pattern |
Eight worked examples
1. "Can you make the logo a little bigger in the header?"
Classification: included revision. The header is an approved element and the change is a size adjustment inside it. No new deliverable, no direction change. Do it and log it in the current round. Requests like this are what included rounds are for.
2. "We showed it to our CEO and she wants to see a version in our old blue instead."
Classification: included revision if the palette was never locked. Change request if it was. Check your scope record. If the brief specified the palette and you approved it together, testing an unrelated color reopens a closed decision, and a new stakeholder's preference does not change that. The kind reply names both facts: yes it is possible, here is the cost and the two extra days, and the approved version stands until you say otherwise.
3. "Also, can we get square and vertical versions of the video for Instagram and TikTok?"
Classification: change request. This is a new deliverable set, not a refinement. Vertical reframing on a finished timeline means repositioning subjects, retiming graphics, and often resubtitling. The effort is real even though the request sounds like an afterthought. Quote it as its own line item. Upwork's scope creep examples describe this pattern: a focused deliverable expanding into a package without corresponding compensation (Upwork).
4. "The whole tone feels off. Can we try a completely different concept?"
Classification: change request, after one clarifying question. Ask first: "Is the concept wrong, or is the execution of this concept not landing?" Those have different prices. If the execution is off, it is a revision. If the concept is wrong, you are back at concept selection, which sits in the divergent half of the process the Design Council's Double Diamond describes, and which you already exited (Design Council). Reopening it is a new phase, priced accordingly.
5. "Our legal team needs a disclaimer added to every page."
Classification: included revision if the page count is unchanged and the layouts absorb it. Change request if it forces relayout. Adding one line of small type to six approved layouts is minor work. Adding a 90 word disclaimer that breaks every grid is not. Classify by consequence, not by who asked. And keep your own lane: you can place legal copy, but you do not advise on whether the copy is sufficient.
6. "Two more quick notes, and then two more tomorrow morning."
Classification: still round two, if you defined a round as one consolidated batch. Fold same window follow ups into the open round and say so in one sentence: "Adding these to round two, which I will deliver Thursday." If the drip continues past the window, the next batch is a new round. Freelancers Union's template supports the mechanism by setting a fixed period in which the client must submit revision requests (Freelancers Union Contract Creator).
7. "Small thing, can you send me the editable source files?"
Classification: change request unless source file delivery is in the scope record. This is not a revision at all. It is a deliverable and, often, a licensing question. Handle the deliverable side in a change request with your stated rate, and handle the rights side through your contract, not an email reply. Ownership and usage terms are a matter for your agreement and a qualified lawyer, not an operational judgment call.
8. "You delivered the thumbnail at the wrong dimensions."
Classification: courtesy fix. If the brief specified 1280 by 720 and you exported 1920 by 1080, that is your error. Fix it the same day, do not log it as a round, and do not narrate it. Absorbing your own defects quickly is what makes your firmness credible on the requests that are genuinely out of scope.
The sentence that does most of the work
When something is out of scope, you need one reply that stays warm and stays firm. This shape works:
"Happy to do that. It falls outside what we scoped, so here is a quick change request: 320 dollars and two extra business days. Approve it and I will start tomorrow. If you would rather keep the current timeline, we can ship as approved and pick this up after launch."
Three properties make it land. It says yes. It states the cost without apology. It offers a path that does not require the client to spend more money.
Making the classification automatic
Classifying requests works better with a written reference than with memory under time pressure. That is the core of Revision Ledger, a 39 dollar working set: a Project Scope Record, a Revision Decision Guide that walks a request to included revision, clarification needed, or paid change request, a revision log for Notion and Google Sheets, a Client Feedback Form, a Change Request template, client email scripts, an AI prompt library for triaging messy feedback, and a 15 minute setup guide.
If the table above is enough for you, use the table. If you want the whole loop already built, the kit is that. It is an operational workflow only. It is not a contract, and it is not legal advice.