Statement of work clauses that make scope questions easy to answer
The deliverable, exclusion, limit, dependency and change-procedure clauses that let you answer “is this in scope?” in seconds, with examples for CRM, migration and integration work.
Key takeaways
- Five kinds of clause answer most scope questions: deliverables, exclusions, limits, dependencies and the change procedure.
- Numbers beat adjectives. “Up to five standard reports” settles a question that “standard reporting” starts.
- Name your exclusions. Silence is not an exclusion, and an argument about silence is an argument you may lose.
- Put client responsibilities in writing, with dates, so a missed dependency is visible when it becomes a request.
- Avoid “to be confirmed” where you can. Where you can’t, say who confirms it, by when, and what happens if it grows.
Why wording decides the answer
When a client asks for something new, the question “is this in scope?” is answered by the statement of work, or not answered at all. The clearer the clause, the faster the answer and the less room there is for disagreement. Vague clauses don’t protect you. They shift the argument to whoever remembers the sales conversation best.
Five kinds of clause do most of the work. Here is what makes each one useful, with examples from CRM, migration and integration projects.
Deliverables
What you will deliver, specifically enough that someone else could check it.
- Weak: “Configure the sales pipeline.”
- Strong: “Configure one sales pipeline with up to seven stages, as listed in Appendix B.”
The strong version answers three later requests in advance: a second pipeline, an eighth stage and a change to the listed stages.
Exclusions
What you will not do, named. Exclusions matter most where a client might reasonably assume something is included.
“Migration covers contacts, companies and open opportunities. Historical invoices, closed tickets and email attachments are excluded.”
A missing clause is not an exclusion. If the agreement simply doesn’t mention invoices, a request to migrate them is unclear rather than plainly extra, and you are negotiating instead of pointing.
Limits
Numbers that cap a deliverable: counts, frequencies, volumes, durations.
- “One sandbox and one production environment.”
- “Up to five standard reports and two dashboards.”
- “A nightly one-way sync of up to 50,000 records.”
- “Two training sessions of up to two hours, for up to 15 people.”
- “Three trial loads before the production cut-over.”
Dependencies
What the client must provide, and by when. Dependencies are where scope quietly moves from the client to you: when the data isn’t cleansed, the request becomes “can you clean it up?”.
“The client will provide deduplicated contact data in the agreed template by the end of week 3. Data cleansing is not included in the supplier’s scope.”
Change procedure
How changes are requested, priced and approved. Keep it simple and specific:
“Changes to scope are requested in writing. The supplier will respond with a change request stating the additional scope, price and schedule impact. No additional work starts until the client’s project sponsor approves the change request in writing.”
This one clause turns every “potentially additional” request into a known next step, and gives you something neutral to point at.
Checklist
| Clause | Ask yourself |
|---|---|
| Deliverables | Could a stranger tell whether this was delivered? |
| Exclusions | Have I named the things the client is likely to assume? |
| Limits | Is there a number wherever “more” is possible? |
| Dependencies | Does each client responsibility have an owner and a date? |
| Change procedure | Is it clear that work waits for written approval? |
| To be confirmed | Who confirms, by when, and how is growth handled? |
When you upload a statement of work to Agreeably, it proposes exactly these five kinds of scope item, each with a quotation checked word for word against your document, for you to correct and confirm. Every later request is checked against that confirmed baseline. See examples by project type.
Frequently asked questions
Do longer statements of work prevent scope creep?
Not by length alone. A short SOW with specific numbers, named exclusions and a clear change procedure is easier to apply than a long one full of general description.
Should the SOW list everything that is out of scope?
List the things a client is likely to assume are included: historical data, extra environments, additional integrations, ongoing support. You can’t list everything, so name the predictable ones.