River
Y CombinatorBacked by Y Combinator

For consultants once the client says yes

SOW Generator From Your Consulting Proposal

A statement of work from your agreed proposal: scope in and out, how each deliverable is accepted, and a tighter version of every vague line.

Free to start. No card needed.

How to write a statement of work by hand

Start with what the client will receive, not the tasks. The State of Oregon's SOW writing guide defines deliverables as the end products or services a contractor submits for acceptance1. Project schedules and progress reports, it adds, usually aren't deliverables: they track progress toward one. Give each deliverable acceptance criteria, which the guide calls the objective criteria used to decide whether work meets requirements. In practice, write down what each must contain, who signs it off, how many working days they have to review it, and what happens if no comments arrive.

Describe the work by its results: "new discount rules, approved by the CFO", not "40 hours of pricing analysis". US federal rules tell agencies to describe work in terms of the required results2 wherever practicable, not by method or hours. Put a number, limit or date on every scope line, since Oregon's guide warns that each side may read words like "assist", "help" and "best efforts" differently. Then list what is out of scope: anything a larger option in your proposal offered that the client didn't choose, plus implementation, training and extra review rounds.

Write every obligation in the active voice, with a named owner: "the client will send the branch sales ledger by [date]", not "data will be provided". Passive sentences, Oregon's guide notes, can leave it unclear who is responsible. Say how the dates move if the client's part arrives late. Tie each payment to a milestone both sides can see, such as an accepted deliverable. Finally, set out the change process: who raises a request, who assesses its effect on scope, time and fee, and that work waits for a signed change order.

How it works

How River writes your statement of work

Use River's SOW generator once the client has said yes, before kickoff. Drop the proposal they agreed to into the box at the top, with any emails that followed, or paste your call notes. River reads all of it before writing, noting each promise word for word and where it appears, plus every date, fee, name and role. If the proposal offered options, it uses the one the client chose. If that isn't clear, it uses the option you recommended and says so at the top.

Then it writes the statement of work into a doc in your workspace, in 10 sections. Every promise for the chosen option stays in scope. The out-of-scope list starts with what your proposal leaves out, such as a second site only a larger option offered. Each deliverable gets a test for done, a sign-off by role and a review window. In a section called Lines that invite scope creep, it quotes each open-ended line, says why it's risky and gives a tighter version.

River never invents a fee, date, name, quantity or deliverable. Each gap stays in brackets, such as [fee], and goes on a checklist of points to confirm before signing, with who should answer it. It leaves legal terms such as liability and confidentiality to your own agreement. If you haven't written the proposal yet, start with the consulting proposal generator. To write the SOW yourself, use the statement of work template, and once it's signed, a RACI matrix template turns its deliverables into who does what.

How it works

From proposal to statement of work

  1. Drop your proposal

    Drop the proposal your client agreed to, or paste your call notes and the emails that followed.

  2. River maps every promise

    It reads everything first, noting each promise in your exact words and where it appears.

  3. Get your SOW

    Your statement of work opens in your River workspace, with brackets wherever your material leaves a gap.

  4. Tighten and sign

    Settle the bracketed points, use the tighter wording you agree with, then send it to your client to sign.

Example

Statement of work · Calder & Moss

  1. Out of scopeChanges to the ERP system, training for sales reps, and any branch beyond the six named.
  2. Deliverable 2 · accepted whenThe CFO approves the discount rules in writing, or [5] working days pass with no written comments.
  3. Payment 2 of 3[fee] on acceptance of Deliverable 2, invoiced within [7] days.
  4. Line that invites scope creep“Support the rollout as needed.” → “Up to [4] half-day sessions with branch managers, ending [date].”

What you'll get

A statement of work from your proposal, with scope creep flagged

  • What's in scope, and an explicit list of what isn't
  • Every deliverable with the test it must pass to be accepted
  • Vague lines quoted from your proposal, each with a tighter rewrite

Before and after

Your proposal in. A SOW with clear edges.

What you drop in (example)

The proposal Calder & Moss accepted: Option 2, a pricing diagnostic and new discount rules for a fixed fee, in three phases over 10 weeks. One line reads: “Support the rollout as needed.”

What you get (example)

Out of scope: changes to the ERP system, training for sales reps, and branches beyond the six named in the proposal. Deliverable 2: Discount rules. Accepted when: the CFO approves them in writing, or [5] working days pass with no written comments. Lines that invite scope creep As written: “Support the rollout as needed.” (proposal, Option 2) Why it's risky: no limit on time, people or end date. Tighter: “Up to [4] half-day sessions with branch managers, ending [date].”

The vague line, why it's risky, and a version both sides can sign.

What lands in your doc

What's in your statement of work

  • Objectives carried over from your proposal, each tied to the deliverable that achieves it
  • Every promise from the option the client chose kept in scope, plus an explicit list of what's out
  • Each deliverable with its contents, its test for acceptance, who signs it off and its due date
  • Client responsibilities such as data, access and decisions, each with an owner and a due date
  • A payment schedule tied to milestones, and a change process where work starts only after written approval
  • Every vague line quoted with a tighter version, and a checklist of points to confirm before signing

Questions consultants ask

Common questions

What is a statement of work?

A statement of work, or SOW, is the part of a contract that sets out the work. It says what will be delivered and by when, how each deliverable is accepted, who provides what, and how payment works. Oregon's guide for state agencies calls it the heart of the contract. In consulting, it turns the option your client chose into commitments both sides sign.

How do I write a statement of work with River?

Drop the proposal your client agreed to into the box at the top of this page, with any emails that followed (up to 10 files), or paste your call notes. River reads all of it, then writes the SOW into your free River workspace. Fees, dates and names come only from your material, and any gap stays in brackets for you to settle.

What is the difference between a proposal and a SOW?

A proposal wins the work and a SOW defines it. The proposal sets out the problem and your approach, often with options. The SOW comes once the client has chosen and turns that choice into commitments: deliverables, acceptance criteria, responsibilities, milestones, payments and a change process. Anything the proposal left to be agreed should be settled in the SOW, or given a date and a way to decide it.

How does a SOW prevent scope creep?

It makes the edges of the work visible before anyone starts. An out-of-scope list, a test for every deliverable and a change process give both sides one answer when a new request arrives: it's in the SOW, or it's a change. In the Project Management Institute's 2021 Pulse of the Profession survey, avoiding scope creep was a top-three driver of project success3 in every industry PMI analyzed.

Is a SOW legally binding?

It can be. A SOW that both sides sign, or that a signed master agreement incorporates, usually forms part of the contract. Oregon's guide for state agencies calls a SOW legally enforceable and subject to contract law, so word it with care. River leaves liability, intellectual property and confidentiality to your own agreement. None of this is legal advice, so ask a lawyer when the stakes are high.

Is my client's proposal kept private?

Files you drop stay in your own River workspace unless you share them. Under River's privacy policy, your files are never used to train AI models, and the AI providers that process them are bound by agreements not to train on them either. If your contract with the client limits where its documents can go, check it first.

Is the SOW generator free?

Yes, it is free to start. Your SOW opens in a River workspace, where you can edit it, share it or ask River to change it. From there, River can also build a RACI or a data request list from the finished SOW. Paid plans add more AI use and access to the most advanced models.