---

title: "Writing proposals and SOWs that prevent problems"

module: 3

module_title: "Expectations & Scope"

order: 1

access: "paid"

summary: "Treat the proposal and SOW as communication documents that make sure both sides are picturing the same project. Covers writing scope for the disagreement rather than the signature, exclusion lists, named assumptions, a built-in change process, and walking the document through live."

related:

• "managing-scope-creep-conversations"
• "having-money-conversations"
• "the-kickoff-meeting"
• "setting-vs-managing-expectations"

---

Writing proposals and SOWs that prevent problems

We once had a two-hour disagreement with a client over the word "reporting." The SOW said phase two included "reporting functionality." To us, that meant a dashboard with four charts we'd discussed on a call. To them, it meant exportable custom reports with filters, scheduled email delivery, and historical comparisons. The call where we'd discussed those four charts? They remembered it differently.

Nobody was lying. Nobody was even being unreasonable. We'd both read the same sentence and seen different projects in it. The $9,000 gap between those two projects came out of our margin, because the document that was supposed to protect everyone was written for the signing, not for the disagreement.

Why the SOW is a communication document

Most people think of proposals and SOWs as sales documents or legal documents. They're really communication documents. Their job is to make sure two groups of people are picturing the same project.

Here's the thing about scope disputes: they're almost never about bad faith. They're about the gap between what was written and what each side imagined. Every vague phrase in an SOW is a place where the client's imagination and yours can quietly diverge. And imaginations always diverge in the direction that favors the imaginer.

Scope creep doesn't start mid-project. It starts on the day the SOW is signed, in whatever sentences were left fuzzy. The document you write in the sales process determines which conversations you'll be having in month three, and whether those conversations take five minutes or two hours.

How I think about this

Write for the disagreement, not the signature. When you're drafting, imagine the tensest moment this project could produce: a deadline approaching, the client asking where feature X is, everyone a little stressed. Then read your draft as evidence in that conversation. Would this sentence settle the question or start an argument? "Reporting functionality" starts an argument. "A dashboard displaying these four metrics, listed below" settles it.

Exclusions are a kindness. A "not included" section feels negative to write, so most proposals skip it. But listing what's out of scope isn't stingy, it's honest. It's also where you catch misalignments while they're still free. I'd rather have a client say "wait, migration isn't included?" before signing than after. Before signing, that's a pricing conversation. After, it's a conflict.

Define your countable nouns. Revisions, pages, templates, concepts, rounds. Any word that has a number in front of it needs a definition, because the client will count differently than you do. "Two rounds of revisions" means nothing until you say what a round is. Is a round one consolidated set of feedback? What if feedback comes in over four days from three people? Say so.

Name your assumptions out loud. Every estimate rests on assumptions: content will be provided by a certain date, the client's API does what its docs claim, feedback arrives within five business days. Unwritten assumptions are risks you've silently agreed to absorb. Written ones become shared responsibilities.

A change process in the SOW makes change orders boring. If the SOW already explains how out-of-scope requests get handled, then raising a change order later isn't a confrontation, it's you following the document everyone agreed to. You're not improvising a difficult conversation. You're running a process.

Walk through it live. Don't just email it. An emailed SOW gets skimmed. The exclusions and assumptions, the parts most likely to prevent problems, are precisely the parts skimming skips. Fifteen minutes of walking through the key sections together is the cheapest insurance you can buy.

What this looks like

The scope section, written for the disagreement

Instead of "Development of reporting functionality":

"Analytics dashboard. A single dashboard page displaying: total sales (daily/weekly/monthly toggle), top 10 products by revenue, customer count over time, and average order value. Data updates nightly. Includes desktop and mobile layouts.

Not included in this phase: custom report builder, CSV/PDF export, scheduled email reports, historical data older than 12 months, and user-configurable charts. Any of these can be scoped as a phase two addition."

The assumptions section

"This estimate assumes:

• Product photography and copy are provided by your team by March 15. If content arrives later, the launch date moves with it, day for day.
• Your inventory system's API supports the endpoints described in its current documentation. If we discover gaps, we'll flag them immediately with options and costs.
• Consolidated feedback on each milestone arrives within 5 business days. One person on your side (you've indicated Sarah) collects and delivers it.
• The site launches on your existing hosting. Migration to new hosting isn't included but can be quoted separately."

The change process paragraph

"Requests outside the scope above are welcome, and they're common. Here's how we handle them: we'll confirm the request is out of scope, send a short written estimate of cost and timeline impact, and wait for your written approval before starting. Nothing out of scope gets built, or billed, without that approval. Small requests (under two hours) get batched and reviewed together monthly."

Walking through it live

On the proposal review call:

"Before you sign anything, I want to spend ten minutes on two sections people usually skim: what's not included, and the assumptions. Not because there's anything sneaky in there, the opposite actually. These are the sections that prevent misunderstandings later, and I'd rather you push back on something today than be surprised in June. So, looking at the exclusions list, does anything jump out as something you expected to be included?"

What goes wrong in proposals and SOWs

Optimistic vagueness. Leaving scope fuzzy because pinning it down might surface a disagreement and slow the deal. This doesn't avoid the disagreement. It reschedules it for mid-project, with interest.

Copy-paste scope. Reusing language from the last SOW because it's faster. The leftover sentences describe the last client's project, and now they're promises you've made to this one.

Defining deliverables but not process. The SOW says what gets built but nothing about feedback timelines, revision limits, or how decisions get made. All the machinery of the project is left to improvisation.

Burying everything important in legal language. If the exclusions are written in a way nobody actually reads, they exist legally but not communicatively. A protected contract and a surprised client is still a bad outcome.

Treating the signed SOW as a filing-cabinet document. The SOW should be the most-referenced document in the project, not the least. If it's good, you'll quote it constantly, and every quote is neutral: "the SOW has that in phase two" is a sentence with no villain in it.

Getting better at this

Do a "fight test" read. Before sending any proposal, reread it pretending you're in month three and the client is upset about a missing feature. Every sentence that wouldn't hold up, tighten.

Keep a dispute journal. Every time a scope question or dispute comes up mid-project, write down which SOW sentence failed to prevent it. Fix that sentence in your template. After a year of this, your SOWs are built from your actual scar tissue, which is worth more than any template you could buy.

Have someone uninvolved read the scope. Ask a teammate who wasn't in the sales calls to read the scope section and describe the project back to you. Whatever they get wrong, a client will get wrong too. The sales calls filled your head with context the document doesn't contain.

Write the exclusions list from the client's imagination. Ask yourself: what will this client assume is included? Their assumptions come from their favorite websites, their last project, their most annoying current problem. Address those specifically.

How this connects

The SOW is where scope creep conversations are won or lost, months before they happen. It's the foundation for money conversations, because clear scope makes pricing questions factual instead of emotional. And it feeds directly into the kickoff meeting, which is where the document turns into working agreements.

Things to try

• Add a "Not included" section to your next proposal with at least five specific items.
• Define what a "round of revisions" means in your template. One consolidated set of feedback, delivered by one person, within a stated window.
• Write down every assumption your next estimate depends on. Put the top five in the SOW with an owner for each.
• On your next proposal call, walk the client through the exclusions and assumptions out loud. Ask what surprises them.
• Pull out your last SOW and fight-test it: find the three vaguest sentences and rewrite them with specifics.

That "reporting functionality" dispute cost us $9,000, but the lesson was worth more. A good SOW isn't the document that wins the deal. It's the document that, eighteen months later, both sides can point to and say "yep, that's what we agreed," and mean it. Boring in exactly the right way.

Template: Scope Section Built for the Disagreement

Use this when: you're drafting the scope of a proposal or SOW and want it to settle arguments in month three instead of starting them.

Channel: Document

```template

[DELIVERABLE NAME]

[ONE-SENTENCE PLAIN DESCRIPTION OF WHAT THIS IS.] Specifically, this includes:

• [CONCRETE ITEM 1 — NAME THE EXACT SCREEN, FEATURE, OR OUTPUT]
• [CONCRETE ITEM 2]
• [CONCRETE ITEM 3 — DEFINE ANY COUNTABLE NOUN: "2 rounds of revisions" means one consolidated set of feedback, delivered by [NAME], within [X] business days]

Not included in this phase: [OUT-OF-SCOPE ITEM 1], [ITEM 2], [ITEM 3], [ITEM 4], and [ITEM 5]. Any of these can be scoped as a phase two addition.

Assumptions this estimate depends on

• [DELIVERABLE FROM CLIENT] is provided by [DATE]. If it arrives later, [DELIVERY DATE] moves day for day.
• [SYSTEM OR API] behaves as its current documentation describes. If we find gaps, we'll flag them immediately with options and costs.
• Consolidated feedback on each milestone arrives within [X] business days, collected and delivered by [ONE NAMED PERSON].

How out-of-scope requests get handled

Requests outside the scope above are welcome, and they're common. We'll confirm the request is out of scope, send a short written estimate of cost and timeline impact, and wait for your written approval before starting. Nothing out of scope gets built, or billed, without that approval. Requests under [TWO HOURS] get batched and reviewed together monthly.

```