Separate a correction, a revision and a scope change
A correction fixes work that does not meet an agreed requirement or contains your error. It is normally your responsibility. An included revision adjusts the agreed deliverable within the stated number of rounds. A scope change adds a new deliverable, behavior, audience, format, integration or decision after the agreement.
Use the definition, not the size of the request. A button color change may be an included revision. Adding user roles to a system can be described in one sentence and still be a substantial scope change. The phrase just one small thing is not a unit of measurement.
- Correction: the delivered work fails an agreed requirement
- Included revision: an adjustment inside the agreed outcome and allowance
- Scope change: new output, behavior, dependency or acceptance criterion
- Client delay: a scheduling issue governed by the agreed timeline terms
Define the revision allowance before the project starts
Do not write two revisions and assume everyone understands the same thing. Define a round as one consolidated set of feedback from the authorized decision-maker, delivered by a stated deadline. Explain whether unused rounds expire and what happens when feedback is fragmented across messages and meetings.
Specify the level of change allowed. A design revision may cover typography, spacing and visual direction while excluding a new page hierarchy or business model. Unlimited revisions only work in tightly productized services with strict boundaries; otherwise the word unlimited tends to eat the margin first.
Use a three-question scope test
First ask whether the request is required by the written acceptance criteria. If yes, it may be a correction. Second ask whether it replaces an included option or adds a new one. Third ask whether it changes dependencies, testing, schedule or responsibility. New consequences usually mean new scope.
When the answer is unclear, pause the affected work and write down the interpretation. A two-minute clarification before implementation is cheaper than discovering at invoice time that the client believed the work was included.
Price the change before doing it
A simple internal formula is: change price = additional hours × the applicable rate + direct costs + a fixed-price risk allowance for remaining uncertainty. Use the contracted rate unless a rush fee, specialist rate or minimum change fee was agreed in advance.
Send a short written change request. It should state what changed, why it is outside the original scope, what will be delivered, the added price, the effect on the schedule, any new assumptions and how the client approves it. Do not begin the extra work while approval is still implied by a thumbs-up emoji from someone who cannot authorize the budget.
- Reference to the original scope or acceptance criterion
- Description of the requested change and resulting deliverable
- Additional price, tax treatment and payment timing
- Revised milestone or delivery date
- New dependencies, exclusions and approval method
Worked example: one small change to a landing page
The approved scope includes one standard lead form and two consolidated design revision rounds. After approval, the client asks for a multi-step form connected to a CRM with analytics events. That is new behavior, a new dependency and additional testing—not a visual revision.
Estimate 7 hours for implementation, 2 for testing and 1 for communication and release: 10 hours. At a rate of 80, labor is 800. Add 50 in direct third-party cost and a 10% allowance on labor for the still-uncertain CRM connection: 80. The change price is 930 before applicable tax, and delivery moves by two working days.
By contrast, changing the button color during an included design round remains included. The rule is based on the agreed outcome and consequences, not on how enthusiastically either side argues that the request is tiny.
Use language that protects the relationship
Keep the message factual: This request sits outside the agreed scope because it adds a CRM integration and new form behavior. I can add it for 930 and move delivery by two working days, or keep the current scope and original date. Please confirm which option you prefer.
That is not a refusal and not a punishment. It gives the client control over budget, scope and time. Calm change control often improves trust because the alternative is usually a surprise invoice, silent resentment or unpaid work disguised as customer service.
Close the loop after approval
Update the estimate, task list, acceptance criteria, timeline and payment schedule. Keep the approval with the project record and make sure everyone working on delivery sees the new boundary.
After the project, review which requests appeared repeatedly. If clients always ask for the same extra, add it as an option in future proposals. Scope control is not only defensive; it is product research wearing a slightly less glamorous jacket.
Put the method into a real estimate
Break the work into tasks, apply time and rates, add discount or tax, and create a clean client-ready PDF without registration.
Open the free calculatorFrequently asked questions
Should I charge for correcting my own mistake?
Normally no. If the work fails an agreed requirement or contains your error, correct it. Charge when the client requests new work or changes an accepted decision outside the included revision allowance.
What if the original scope is vague?
Clarify the boundary now and document the agreement before more work continues. Avoid surprising the client with retroactive charges, but do not accept open-ended future work because the first document was weak.
How should I handle many tiny changes?
Collect them into the next included revision round or a scheduled change batch. A disclosed minimum change fee can cover administration, but it should be agreed before the requests arrive.
