How to Tell a Client Something Is Out of Scope (Without Losing Them)

A bad reply costs you either way. Say yes on reflex and you're doing unpaid out of scope work that sets a precedent. Say no too bluntly and a good client starts to feel nickel-and-dimed. This guide shows how to tell a client something is out of scope without either outcome: a quick check against your SOW, six principles for the reply, copy-paste email templates, and a change request template so you get paid for the extra work.

Before You Reply: Confirm It's Actually Out of Scope

Most awkward scope conversations start with a reply sent from memory. Before you write anything, open the agreement. Sometimes the request is covered and the right answer is a quick yes. Sometimes it's clearly extra. And sometimes the agreement simply doesn't say.

In Scope, Out of Scope, or Grey Zone?

The question of in scope vs out of scope has three possible answers, not two:

• In scope. The agreement includes the work, either explicitly or as a clear part of a listed deliverable. Do it and confirm briefly.
• Out of scope. The work isn't in the agreement, goes past a stated limit (a third round of revisions when two are included), or is named as an exclusion. This is where the rest of this guide applies.
• Grey zone. The wording is ambiguous, or the client reasonably expected something the agreement never addressed: “launch support” with no end date, or “website copy” when you meant editing and they meant writing. Grey-zone requests need a clarifying question, not a verdict.

Be honest about the grey zone. If the SOW is vague, part of the misunderstanding belongs to whoever wrote it, which is usually you. That doesn't mean you do the work for free. It means you lead with a question instead of a no. For worked cases across web, design, marketing and consulting projects, see these scope creep examples from client projects.

What to Check in Your SOW

This check is only as good as the document behind it; if yours is thin, this agency scope of work template shows what each section should cover.

Read the agreement the way the client will when you quote it back to them. Check six things:

1. Deliverables. Is the request a listed deliverable, part of one, or something new? Look for quantities: “up to eight pages”, “four blog posts a month”.
2. Number of revisions. How many rounds are included, how is a round defined, and how many have you already used?
3. Exclusions. Is the work named as not included? An explicit exclusion is the easiest conversation you'll have.
4. Assumptions. Many SOWs list what the client provides, like copy, images, system access or feedback within a set time. A request can be out of scope because an assumption broke, not because the deliverable changed.
5. Timeline. Does the request fit the agreed phases and dates? Work requested after launch, or after a support window closes, often falls outside.
6. Communication channels. Does the agreement say how changes are requested and approved? If it names a process, such as “changes are handled through a written change request”, your reply should follow it.

Note the section number or copy the exact sentence. You'll quote it in your reply.

This is the check Scovara automates. You import your SOW or contract, your team confirms the scope extracted from it, and each client request is compared against that scope and classified as in scope, needs review or potential out of scope, with the relevant clause cited.

How to Tell a Client Something Is Out of Scope (Professionally)

The structure of your reply matters more than the exact wording. These principles apply whichever template you start from.

1. Reply fast. A request left unanswered for days starts to look accepted. If you need time to price it, acknowledge it the same day: “Got it. This one sits outside our current scope, so I'll send you options by Thursday.”
2. Don't apologize for your boundaries. “I'm so sorry, but unfortunately…” tells the client the scope is negotiable and that you feel guilty about it. You both agreed to the scope. State it plainly and kindly.
3. Reference the agreement. Quote the clause or name the section: “Our SOW covers two rounds of revisions on the homepage (Section 3.2).” That turns your opinion into a shared fact.
4. Separate the “no” from the “how”. First, say whether it's covered. Then say what you can do about it. Blending the two (“it's not really included, but maybe we could possibly…”) makes both unclear.
5. Always offer a path forward. A bare no ends the conversation; a no with options keeps the project moving. Three options cover most cases: a change request (priced and scheduled now), a next phase (added after the current scope ships), or a swap(replacing something already in scope that takes similar effort).
6. Confirm in writing. If the request came in Slack, on a call or in passing at a meeting, follow up with an email that states what was asked, what you said and what happens next. Memory is a poor record of scope decisions, yours and the client's.

Out-of-Scope Email Templates (Copy and Paste)

Each out of scope email template below has a note on when to use it, a subject line and a short body. Replace the [placeholders], keep the structure, and adjust the tone to the relationship. Treat them as a starting point, not a script: any scope creep email template sounds canned if you send it unedited.

These templates are sample wording written for this guide. Adapt them to your own agreement; none of this is legal advice.

Hi [Name],

Thanks for sending this over. [Request] is a good idea, and I want to flag early that it sits outside our current scope. Our SOW covers [what's included, e.g. "design and development of up to eight pages"], and this would be [an additional page / a new deliverable].

Happy to help with it. I can put together a quick change order with the cost and timing, or we can plan it for the next phase so it doesn't affect the current launch date. Which would you prefer?

Best,
[Your name]

Hi [Name],

Yes, we can do this. Since [request] isn't part of the current agreement ([section or clause]), here's what it would involve:

- What's included: [short description of the work]
- Price: [$amount, or $rate per hour with an estimate]
- Timeline: [effect on delivery, e.g. "launch moves from (date) to (date)"]

If that works for you, reply to approve and I'll send the change order to sign. We'll start as soon as it's approved.

Thanks,
[Your name]

Hi [Name],

Before we go further on [request], I want to step back. Over the last [few weeks], we've taken on [number] items that weren't in the original scope: [item], [item] and [item]. We were glad to help, but together they're adding real time to the project.

Going forward, anything outside the SOW will go through a change order before we start, so you see the cost and timing up front and nothing comes as a surprise. For [request], I'll send one by [day].

If it would help, I'm happy to get on a call and walk through what's in scope and what's left in the plan.

Best,
[Your name]

Thanks [Name]! Quick flag: [request] isn't in our current SOW, so I don't want to start it before we've agreed the details. I'll email you options (cost and timing) by [day].

Hi [Name],

Following up on your Slack message from [date] about [request], so we have it on record.

This falls outside our current scope: the SOW covers [relevant deliverable or clause]. Here are the options:

1. Add it now through a change order: [$amount], [timeline impact].
2. Schedule it for the next phase, after [milestone].
3. Swap it for [in-scope item of similar effort], if that one matters less right now.

Let me know which you'd like, and I'll take it from there.

Best,
[Your name]

Hi [Name],

Before I answer on [request], I want to make sure I understand what you have in mind:

- [Is this replacing (existing item), or in addition to it?]
- [Who will use it, and what do they need it to do?]
- [Is there a date it needs to be ready by?]

Our SOW mentions [relevant clause], but it doesn't spell out this case, so I'd rather check than guess. Once I hear back, I'll confirm whether it's covered or send a short proposal if it isn't.

Thanks,
[Your name]

Hi [Name],

I hear you, and on the surface it does look small. On our side, [request] means [what it actually involves, e.g. "a new page template, testing across devices and another review round"], which is outside what the SOW covers ([section]).

I don't want to say a quick yes and then have the timeline slip, so here's what I suggest: [option, e.g. "a fixed fee of $amount, delivered by (date)"]. If you'd rather keep the budget as is, we can [swap it for (item) / add it to the next phase].

Let me know what works best.

Best,
[Your name]

How to Charge for the Extra Work: Change Request (Change Order) Template

Once the client agrees the work is extra, put it in writing before you start. A change request is a short document that describes the new work and records the client's approval. US teams often call it a change order. It's the same idea, so use whichever term your agreement uses.

A useful change request includes:

• Description of the change: what will be delivered, specific enough that both sides would agree when it's done.
• Reason: what prompted it, usually the client's request and the date it was made.
• Impact on timeline: which milestones or delivery dates move, and by how much.
• Price or pricing method: a fixed fee, or an hourly rate with an estimate and a cap.
• Approval line: who on the client side approves, with a signature or written confirmation and a date.

Keep it to one page. You want a quick yes, not a second contract. Reference the original agreement so the change request reads as an addition to it, not a replacement.

CHANGE ORDER #[number]

Project: [project name]
Client: [client company]
Original agreement: [SOW or contract name and date]
Date requested: [date]
Requested by: [client contact]

1. Description of the change
[What will be delivered, with quantities where possible.]

2. Reason for the change
[e.g. "Client request on (date) to add a partner directory page, which is not in the approved sitemap (SOW Section 2.1)."]

3. Impact on timeline
[Milestones or dates affected, e.g. "Launch moves from (date) to (date)."]

4. Price
[Fixed fee: $amount] or [Hourly: $rate per hour, estimated (number) hours, not to exceed $amount]
Payment terms: [e.g. invoiced with the next milestone]

5. Other terms
All other terms of the original agreement remain unchanged.

Approval
Approved by: ____________________
Name and title: [client approver]
Date: ____________________

What to Do When the Client Pushes Back

Pushback is normal, and it's often about surprise more than money. Stay calm, go back to the agreement, and keep offering a way forward.

“We assumed it was included.”

Take the assumption seriously; it's often sincere. Point to what the SOW does say. If the wording really left room for their reading, acknowledge it. You can absorb part of the work as a one-off, stated as such in writing, or split the request into the covered part and the extra part. Then tighten the wording in your next agreement.

“Another agency (or freelancer) would include this.”

Maybe they would, in their price. Don't argue about other providers. Explain what your fee covers and that this changes the work: “Our fee is based on the scope we agreed. I'm happy to add this, and here's what it would cost.” If the comparison matters to them, it's a conversation for the next contract, not a reason to work for free on this one.

“It's urgent.”

Urgency changes the timing, not the scope. Offer the fastest path: a change request you can turn around today, with an honest note on what moves if you prioritize it. If something already scheduled has to slip, name it and get approval for that too. Rushed out of scope work without written approval is how a favor turns into a dispute.

“We don't have budget for this.”

Then offer the options that don't need new budget: a swap for something of similar effort that matters less right now, or moving it to a later phase. A clear “not now” is still a path forward.

How to Prevent the Next Out-of-Scope Request

Client scope creep rarely comes from bad intent. It comes from vague agreements, too many channels and quick yeses. Four habits close most of the gaps:

1. Write clear exclusions in the SOW. List what isn't included, not only what is. “Video production is not included” prevents a conversation before it starts. These common scope creep examples show which missing exclusions cause the most trouble.
2. Set revision limits and define a round. “Two rounds of consolidated feedback per deliverable” is checkable. “Revisions until you're happy” is not.
3. Use a single request channel. Ask clients to send new requests to one place, whether that's email, a shared Slack channel or a project board, so nothing gets agreed in passing. Put the scope change request process in the agreement itself, so everyone knows what happens next.
4. Run a scope check on every new request, including the small ones. Most scope creep starts with a yes given from memory.

That last habit is the one Scovara is built for. It checks each client request against your SOW, whether you paste it in or it arrives in a mapped Slack channel, and flags potential out-of-scope work with the clause cited, before you say yes.

Common Questions About Out-of-Scope Requests

Is it rude to say something is out of scope?

No. What damages a relationship is a surprise invoice the client never approved, or work you quietly resent doing. Saying it early, plainly and with options is the professional move, and telling a client the cost before the work starts is the respectful one.

Should I do small out-of-scope tasks for free?

Sometimes, on purpose. A five-minute favor for a good client can be worth it. Do it as a stated exception (“Happy to do this one at no charge; anything similar going forward would go through a change request”) and keep a note of it. The problem is doing small things for free by default, because they add up and they set expectations.

What's the difference between a change request and a change order?

In practice, usually nothing. Both describe the extra work, its price and its effect on the timeline, and record the client's approval. Some teams use “change request” for the client's ask and “change order” for the approved document. Use whichever term your agreement uses.

How do I say no to extra work in an email?

Say that the request is outside the agreement, reference the clause, and offer at least one option: a change request, a later phase or a swap. Skip the apology. A good out of scope email reply is short: one line on the scope, one on the options, and a question asking which they prefer. The templates above follow that structure.

What if the SOW is vague?

Treat the request as grey zone. Ask clarifying questions, agree what's fair for this project, and write the decision down. Then fix the wording in your next SOW with named exclusions, quantities and revision limits. A vague agreement is a reason to talk, not a reason to work for free.