Client delivery · Kit & File Field Notes
How to Handle Out-of-Scope Client Requests Without Souring Things
Quote it, swap it, or park it, and start nothing until the client chooses in writing. Scripts for handling scope creep without souring the relationship.
"Can you also just..." is how a fixed-scope project quietly stops being fixed. The fix isn't saying no more often. It's answering every extra ask the same way, in writing, with a choice for the client to make.
Check the request against the scope
Before you reply, open the written scope. Sort the request into one of three piles:
- In scope: do it.
- Out of scope: an extra deliverable, an extra revision round, a change to something already approved, a new feature, or a compressed deadline.
- Unclear: the scope doesn't say. Treat it as out of scope for now and say why.
Here's the rule I'd use: any request outside the agreed scope gets a change order. Not sure if it's in? The written scope answers that, not your memory of the call.
Reply with options, not a verdict
Say yes to the person and be clear about the work. Acknowledge the request, say plainly that it sits outside what you agreed, and give them a choice.
Quote it
Happy to help with [request]. It's outside the current scope, so here's what it would take: [fee], and it moves delivery from [date] to [date]. Reply "approved" and I'll add it.
Swap it
We can fit [request] in by swapping it for [in-scope item], with no change to the price or date. Want to make that swap?
Park it
Good idea. It's outside this project, so I'll note it for a next phase once we've delivered [current deliverable].
Each reply ends with one choice for the client to make, the habit the clear next action guide covers. Some clients will leave over a clear boundary. That's useful information too.
Give free extras on purpose
Small extras can be good business when you choose them. Say so out loud so the boundary stays visible. I'd send the same change note with a $0 fee marked "goodwill this once", so the client still replies approved and the habit stays intact.
Happy to do [small item] at no charge this once. For the record: [item], $0, no change to the date. Reply "approved" and I'll start.
Generous, and on the record. Both matter.
Write it down, then wait for a written yes
A change note is a short written record of a scope change. For a lot of small projects, an email the client replies to is enough. If your contract spells out a process, follow it.
The change note:
- Original scope line: what was agreed.
- Requested change: in one sentence.
- Fee: the amount, or $0 for goodwill.
- Timeline impact: the new date, or "no change".
- Approval: "Reply 'approved' to confirm."
Then wait. Don't start the extra work until the change is approved in writing. Jennifer Bourn's out-of-scope script makes the case for change orders even when a signed contract is in place.
Why so strict? Because starting first turns a decision into a debt.
Handle pushback and make it routine
When the client says "can't we just include it?", don't argue about fairness. Restate the original deliverable in one line, then offer the choice again:
The project covers [original deliverable]. [Request] is extra, so the options are the quote, a swap, or a later phase. Which works best?
Keep shipping the in-scope work either way.
To make this routine, log requests in your weekly status update: received, quoted, approved, or parked. The best prevention is upstream. Agree how changes work at onboarding and put the change rule in your proposal. Anything still parked at the end goes into the summary at closeout.
Kit & File writes its own limits plainly on its services page, for example: "No unlimited revisions or fulfillment of the client's own service."
Illustrative example (fictional)
Midway through a website project, the client writes: "Can you also do the newsletter?" The designer replies that it's outside the website scope and offers a quote for a newsletter template with a new date, or parking it until after launch. The client chooses to park it, and it goes on the weekly update as "parked".
For writing replies like these, the Better Messages Kit has a guide, a workbook, and reusable prompts.
The next time a client asks if you can also just do one thing, answer with options.
Questions
Frequently asked questions
What is an out-of-scope request?
It's any ask that isn't in the agreed scope, such as an extra deliverable, extra revisions, a change to approved work, or a faster deadline.
How do I say no to extra work politely?
Acknowledge the request, say plainly that it falls outside what you agreed, and offer options: a quote, a swap for something in scope, or doing it later. Let the client choose.
What should a change order include?
The original scope line, the requested change, the fee, the effect on the timeline, and a clear approval step. For small projects, an email the client replies "approved" to can serve as the record.
Should I start extra work before the client approves it?
No. Start only after the client approves the change in writing. Starting first turns a business decision into an awkward debt.
Is it OK to do small extras for free?
Yes, if you choose to. Say it's a one-time goodwill item so the boundary stays visible for the next request.
How do I prevent scope creep in the first place?
Write a clear scope with deliverables, a definition of done, and a not-included list before work starts, and agree how changes will be handled.
Put the guide to work
Better Messages Kit
The Better Messages Kit helps you write difficult messages clearly, with a message-writing guide, workbook, reusable prompts, and a quick-reference sheet.
See what is included →