How to write SOW exclusion clauses that hold up when the client pushes back
A practical guide to drafting out-of-scope language for agency SOWs: the five exclusion patterns that work, the vague ones that fail, and copy-ready clause wording.
Key takeaways
- An exclusion only protects you if a PM can point to it in under a minute during a live conversation.
- Name the thing, the boundary and the route back in: every exclusion should end with how the work could be added.
- Replace adjectives ("minor", "reasonable", "standard") with counts, lists and named systems.
On this page (5 sections)
Why most exclusion clauses fail in practice
Most agency SOWs have an "Out of scope" heading. Very few have an out-of-scope section that a project manager can actually use on a Tuesday afternoon when a client writes "can we just add Apple Pay while you're in there?" in Slack. The clause exists, but it was written to make the document feel complete, not to settle a question quickly.
When we review SOWs during onboarding, the failure modes repeat. The exclusions are written as a catch-all ("anything not expressly listed above"), they use adjectives that invite argument ("minor content changes are included"), or they exclude a category so broad that nobody believes it applies ("third-party integrations"). Each of these is technically defensible and practically useless. A PM is not going to open a conversation by quoting a catch-all clause to a client who has been a pleasure to work with for six months.
A good exclusion clause does three jobs at once. It tells the client, in plain language, what is not being built. It tells your own team where the line sits so they stop guessing. And it gives everyone a polite, pre-agreed route for adding the work later. If a clause does not do all three, it will not survive the first real request.
Five exclusion patterns that hold
These are the patterns we see in contracts where scope conversations stay short and friendly. They work because they replace judgment calls with facts that both sides can check.
1. The named-system exclusion
Instead of excluding "integrations", list the systems that are in scope and say everything else needs a change order. Clients can read a list. They cannot read your mind about what an integration is.
The Services include integration with Stripe (card payments) and HubSpot (contact sync) as described in Section 3.2. Integration with any other payment provider, wallet (including Apple Pay and Google Pay), CRM, ERP or marketing platform is outside the scope of this SOW and may be added through a Change Order under Section 9.
2. The counted exclusion
Revision rounds, page templates, report variants, ad sizes, locales, user roles. If it can be counted, count it, and say what happens at count plus one.
Each design deliverable includes two (2) rounds of consolidated revisions. A round is one set of written feedback delivered by the Client's named approver within five (5) business days. Additional rounds are billed at the rates in Schedule B.
3. The environment exclusion
Engineering scope leaks through environments more than features. Browsers, devices, OS versions, hosting targets and data volumes all deserve explicit limits.
The application will be tested on the latest two major versions of Chrome, Safari and Edge on desktop, and Safari on iOS 17 and later. Internet Explorer, Android WebView and any browser not listed are excluded.
4. The dependency exclusion
Some work is out of scope because it belongs to someone else: content, data cleansing, legal copy, third-party API fixes. Say who owns it and what happens if it arrives late or broken.
The Client will supply final copy and imagery for all pages by the dates in Schedule A. Copywriting, image sourcing, data cleansing and content migration beyond the 40 product records listed in Section 3.4 are excluded.
5. The phase exclusion
Some requests are good ideas that belong to a later phase. Naming the phase in the contract makes "not now" sound like a plan rather than a refusal.
Native mobile applications, offline mode and multi-language support are planned for a subsequent phase and are not part of this SOW. The Agency will provide an estimate for these items on request.
Words to remove from every SOW
A quick way to strengthen an existing template is to search it for words that sound reassuring but leave the boundary open. Each of these has caused a dispute we have seen in an onboarding audit.
| Vague wording | Why it fails | Replace with |
|---|---|---|
| Minor changes included | Nobody agrees on minor | Changes under 2 hours each, up to 8 hours per month |
| Standard integrations | Every client has a different standard | A named list of systems and endpoints |
| Reasonable revisions | Reasonable expands under deadline pressure | Two consolidated rounds per deliverable |
| Responsive design | Implies every device ever made | Breakpoints at 390, 768 and 1280 px |
| Ongoing support | Open-ended in time and effort | 30 days of defect fixes after launch |
| Best practices | Can be used to justify any request | A named standard such as WCAG 2.2 AA |
You will notice the replacements are not more aggressive. They are more specific. Specific language tends to make clients more comfortable, because it shows you have thought about their project rather than pasted a template.
Always include the route back in
An exclusion that ends with a full stop reads as a refusal. An exclusion that ends with "may be added through a Change Order under Section 9" reads as an option. That small sentence changes the tone of every future conversation, because the PM is no longer saying no. They are pointing to a process the client already signed.
Section 9, or wherever your change control lives, should then be short and mechanical: who can request a change, who estimates it, how long the estimate takes, what it does to the timeline, and who signs. If the process takes three weeks and a meeting with the founder, people will route around it and the work will be done informally. If it takes a day, people will use it.
Keeping exclusions alive after signature
Even a well-written exclusion goes stale if nobody reads it after kickoff. The PM who negotiated the SOW moves to another account, a new developer picks up the ticket, and the clause sits in a PDF that nobody opens. The most common pattern in our onboarding audit is not a missing exclusion. It is an exclusion that existed and was never checked when the request arrived.
- Copy the exclusion list into the project kickoff deck and walk the client through it in the first meeting, framed as "what we will plan for later".
- Pin the in-scope and out-of-scope lists in the internal project channel so developers see them before they reply to a client.
- Tag tickets that touch an excluded area during backlog grooming, before anyone estimates them.
- Review the exclusions at each milestone sign-off and record any that were waived on purpose, so the waiver is a decision rather than an accident.
This is the part TWINJAM automates: the SOW parser extracts every exclusion as a rule, and requests in Slack, Teams, Jira or GitHub are compared against those rules as they arrive. But the habit matters more than the tool. An agency that reads its own exclusions at the right moment will have short, calm scope conversations. One that does not will have long ones, no matter how good the drafting was.
TWINJAM is not a law firm and this is not legal advice. Have your MSA and SOW templates reviewed by qualified counsel in your jurisdiction, and use the patterns above as a brief for that review.
Ananya Iyer
Head of Contract Research, TWINJAM
Ananya leads the team that turns signed SOWs into boundary rules. She spent seven years in commercial contracting for digital agencies before joining TWINJAM.
Newsletter
The Profitable Agency
Weekly teardowns of agency contract terms, margin protection and delivery operations. One email every Thursday, no fluff.
Read by delivery leads and agency founders. Unsubscribe in one click.