Statement of work (SOW) template: free example

This page may contain affiliate links from which Blur Studio earns commissions.

A statement of work is where most project disputes actually get decided, not in the broader contract, because it's the SOW that says what was actually promised. If you're searching for a template, you're probably about to start a specific project and want deliverables and price locked down in writing before work begins, rather than relying on what was discussed verbally or in a proposal email.

Sections a SOW needs

• Project overview. One or two sentences on what this project is and why, enough context that someone reading it in a year understands the purpose without digging through old emails.
• Deliverables. The specific, countable things being produced, "a 12-page responsive website with the five pages listed in Exhibit A" rather than "a new website." Specificity here is what prevents scope arguments later.
• Timeline and milestones. Start date, key milestone dates, and final delivery date. For longer projects, breaking the timeline into milestones with their own dates makes it much easier to tell early if something's slipping.
• Pricing tied to milestones. Whether it's a flat fee, hourly with a cap, or milestone-based payments, tie the payment schedule to the same milestones listed above rather than stating them separately, so it's unambiguous what triggers each invoice.
• Assumptions and exclusions. What you're assuming will be true (the client provides content by a certain date, existing branding assets are usable as-is) and what's explicitly excluded (hosting setup, ongoing maintenance after launch). This section does more to prevent disputes than any other, since most scope arguments come from something neither side explicitly addressed.
• Sign-off. Signature lines for both parties, and if this SOW sits under a master services agreement, a line referencing that MSA by name and date.

Naming who actually has approval authority

For any client with more than one decision-maker, add a line naming specifically who can approve milestones and sign off on change requests on the client's side. Without this, it's common for one stakeholder to informally approve a direction in a meeting, work proceeds on that basis, and a different, more senior stakeholder later disagrees with the direction entirely, leaving the provider stuck between two people on the same team who disagree about what was actually authorized. Naming the approver up front in the SOW itself heads this off before it costs you a redo, and it also gives you something concrete to point back to if a different stakeholder tries to relitigate an already-approved milestone weeks later.

A filled-in example

For a small business website redesign: "Project Overview: Redesign of [Client]'s public website to improve mobile usability and update branding, under the Master Services Agreement dated October 1, 2026. Deliverables: Redesigned homepage, services page, about page, contact page, and blog template (5 pages total), responsive on mobile and desktop, built in the client's existing content management system. Timeline: Kickoff November 10, 2026. Wireframes delivered November 24. Design review December 8. Final delivery and launch December 22. Price: $6,500 total, 30% due at kickoff, 40% due at design approval, 30% due at launch. Assumptions: Client provides final copy and images by November 17. Existing logo and brand colors will be used as-is, no new branding work is included. Exclusions: Ongoing hosting, SEO content writing, and e-commerce functionality are not included in this scope." Notice how specific the deliverables and exclusions are, that specificity is the whole point.

A clause people forget: revision rounds

For design, writing, or creative work specifically, state how many rounds of revisions are included in the price, "up to two rounds of revisions per deliverable, additional rounds billed at $X per round." Without this, "revisions" quietly becomes unlimited in the client's mind and finite in yours, and that mismatch is one of the most common sources of frustration on creative projects specifically, more than on technical or physical work where deliverables are easier to define as simply done or not done. State too whether feedback needs to come from one consolidated point of contact or can arrive from multiple people on the client's side, scattered, conflicting feedback from several stakeholders disrupts a project's timeline almost as much as unlimited revision rounds do, and both are preventable with a sentence or two written into the SOW up front. Teams using AI for drafts can read how AI changes revision rounds.

Sign off and change control

Get the SOW signed before kickoff, not after work has already started, through QuickSigner, an electronic signature tool for sending documents out to be signed online instead of printing and scanning them, which is enforceable the same way a wet-ink signature is under the US ESIGN Act and state UETA laws. Once work is underway, any change to deliverables, timeline or price should go through a separate change order rather than an informal email agreement or a verbal "sure, we can add that." A change order is a short document referencing the original SOW, stating what's changing and the adjusted price or timeline, signed by both sides before the new work starts. Skipping this step is how scope creep happens, a client asks for "one small addition" over email, you say yes to keep things moving, and three small additions later you've done meaningfully more work than the original price covered with nothing in writing to point to.

A mistake that shows up in the assumptions section specifically

A branding consultant I know priced a rebrand project assuming the client would supply their own stock photography license, since that's standard for how she normally works, but never wrote that assumption into the SOW itself. The client assumed the opposite, that sourcing and licensing images was part of the $3,000 project fee. Neither side was being difficult, the gap only became obvious three weeks in when the consultant sent a mockup with placeholder images and asked the client to supply the real ones. The client pushed back, the consultant pushed back, and the project stalled for a week over something that would have taken one sentence to settle up front: "Client is responsible for sourcing and licensing all photography used in final deliverables." The lesson generalizes past photography specifically: anything you're assuming the other side will handle, content, access credentials, existing files, approvals from a third party, belongs in writing in the assumptions section, not in your head, because an unstated assumption only surfaces once it's already caused friction.

How I'd approach this

I'd write the assumptions and exclusions section before anything else, it's the part people write last if at all, and it's the part that actually prevents the arguments. For any project where the client is new to you or the scope involves a lot of moving pieces, I'd also build in a milestone-based payment schedule rather than one lump sum at the end, since it forces regular check-ins on whether the project is actually on the agreed path and gives you leverage to pause if a client stops engaging or stops paying partway through. The other habit worth building: review the SOW against actual progress at each milestone, not just at the end, five minutes checking "are we still matching what we wrote down" catches drift while it's still a small conversation rather than a dispute over the final invoice. This matters more than it sounds like it should, because the people doing the actual work are often the last to flag that a project has quietly drifted from its original scope, they're focused on finishing what's in front of them, not auditing the original document against it.