A statement of work template for freelance designers (with examples)

The eight sections every freelance design SOW needs, what to write in each one, and the language that prevents the most common scope and payment disputes.

A statement of work is the document that prevents a $4,000 brand identity project from turning into a $7,500 one without anyone noticing. It is the contract a freelance designer sends after a discovery call, before any work begins, and it specifies — in writing — what is being made, when it ships, what it costs, and what happens when something changes.

Most freelance designers do not send one. They send a quote in the body of an email, get a “looks good, let’s start,” and treat that as authorization. The work begins. Three rounds in, the client asks for “a quick second logo direction.” Then a different typography exploration. Then animated versions for Instagram. The original two-direction, three-revision quote has quietly turned into a four-direction, six-revision project, and the designer is now working at a fraction of the rate quoted because the SOW never specified what the rate was protecting.

This article lays out the eight sections every freelance design SOW should contain, the specific language for each, and the parts most templates online get wrong. The structure is the same one used for the SOW page template included in FoxWork OS, but the content here works in any tool — a Google Doc, Notion, PandaDoc, or a printed page if a client insists.

What an SOW actually does

Two things, equally important.

It is a contract. It defines the obligations of both parties and what happens if either side fails to meet them. If a dispute reaches a small-claims court or a chargeback hearing, the SOW is the document a judge or payment processor reads.

It is a scope reference. During the project, when the client asks for something that was not in the original brief, the SOW is what the designer points to. “That’s outside the scope we agreed on. I can do it as an add-on at $X, or we can revisit it in a separate engagement.” Without the document, that conversation has no anchor and the designer always loses.

The SOW does not have to be long. Three pages is plenty for a typical freelance design engagement. The eight sections below cover everything a one-or-two-person design practice needs.

Section 1: Project overview

A two-to-four-paragraph summary of what is being made and why. This is the section the client reads first; it is also the section a future-you will read when the project’s email thread has gone cold and you need to remember what was actually agreed.

What goes in it:

The client’s company name and project label
The business problem the work is solving (a sentence, in the client’s own framing)
The deliverable category (visual identity, website, marketing collateral, app interface, etc.)
The intended audience for the deliverable

What does not go in it: timelines, fees, deliverable lists. Those have their own sections.

A short example for a brand identity engagement:

Project: Identity system for Northcross Botanicals.

Northcross Botanicals is a five-year-old skincare brand based in Portland repositioning from direct-to-consumer to retail wholesale. The current visual identity (developed in 2021) was designed for digital channels and does not perform on physical retail packaging. This engagement produces a refreshed visual identity system suitable for retail packaging, wholesale sales materials, and updated digital touchpoints.

Audience: independent retail buyers at boutique apothecary and wellness stores, secondary audience of existing direct-to-consumer customers transitioning with the brand.

That paragraph clarifies more than three pages of marketing language about the project would. Context the designer can refer back to. Specific enough that a court would understand the engagement. Plain enough that the client recognizes their own situation in it.

Section 2: Scope of work

The deliverables list. Every concrete output the designer is producing, by name and quantity.

This section is the one that prevents the most disputes, and it is also where most freelance designers under-invest. The trap is being too vague. “Brand identity” is not a deliverable. “Logo” is not a deliverable. “Logo with primary mark, secondary mark, and three sub-brand variants, all in CMYK and RGB, vector and raster” is a deliverable.

The format that works:

DELIVERABLES

1. Primary logo
   - Wordmark and combination mark variants
   - Provided in vector (.ai, .svg) and raster (.png at 1×, 2×, 3×)
   - Provided in CMYK, RGB, and single-color (black and reversed)

2. Color system
   - 5 colors maximum
   - Provided as Pantone, CMYK, RGB, and HEX values
   - Documented in a one-page reference sheet

3. Typography system
   - 1 display typeface and 1 text typeface
   - Recommendations from Adobe Fonts or Google Fonts only
     (no separately-licensed faces unless the client provides the license)
   - Documented usage hierarchy in a one-page reference sheet

4. Brand guidelines document
   - 12-to-16-page PDF
   - Covers logo usage, color, typography, voice (provided by client),
     and three example applications (selected from list below)

5. Three example applications
   - Selection from: business card, letterhead, social profile graphic,
     packaging label, retail signage, web banner
   - Final selection confirmed during kickoff

6. Final asset package
   - All source files, organized into folders by deliverable
   - Delivered via Google Drive or Dropbox link

Notice what is being done in that list. Each deliverable specifies what is included and what is not. The typography section specifies which font libraries are in scope, ruling out a request later for a custom-licensed display face. The example applications specify a maximum of three, with the specific options pre-listed — protecting against a client asking for “just one more” mid-project.

The more concrete the deliverables list, the less negotiation happens during the project. Aim for the level of specificity where, if a stranger read the list, they could verify whether it had been completed.

Section 3: Out of scope

The companion to Section 2. The list of things that are explicitly not part of this engagement, even though they are sometimes assumed.

This section feels redundant when writing the SOW and feels essential the first time it saves an argument. Common items that belong here for a brand identity project:

Photography or illustration (commission separately)
Copywriting beyond the typography reference text
Website design or development
Print production management or vendor sourcing
Trademark registration or legal review of the marks
Animated logos or motion design

For a website project, the equivalents:

Copywriting (provided by client)
Photography or illustration
Custom illustrations or icon system beyond the icon set listed in scope
Email template design
Marketing analytics implementation beyond Google Analytics
Ongoing maintenance after launch

Adapt the list to the project. The rule of thumb: if a reasonable client could plausibly assume something was included, list it as out of scope.

Section 4: Process and timeline

What happens, in what order, and how long each phase takes.

A workable structure for a brand identity project:

Phase	Description	Duration	Client touchpoints
1. Discovery	Brand audit, stakeholder interviews, competitive review	1 week	Kickoff call, audit deck review
2. Strategy	Positioning sprint, mood boards, direction selection	1 week	Strategy presentation, direction approval
3. Design	Logo and system design across selected direction	2 weeks	Round 1 review, Round 2 review
4. Refinement	Final adjustments based on feedback	1 week	Round 3 review
5. Production	Guidelines document, applications, file packaging	1 week	Final handoff
Total		6 weeks

This is not the schedule. This is the standard schedule. Real projects have client delays, vacation gaps, and round-trip review cycles that take longer than expected. The SOW should also include a clause about how delays affect the timeline:

Each review phase assumes a client response within 5 business days of presentation. Reviews returned later than 5 business days may shift downstream phases on a one-day-for-one-day basis. The designer’s working schedule may not always allow same-day resumption after a delayed response.

Without that clause, a designer who blocked four weeks for a project loses that block when the client takes a vacation halfway through. With it, the designer is free to slot other work into the gap and the client understands the contract.

Section 5: Revisions and change requests

The section freelance designers most commonly under-write, and the section that most commonly costs them money.

The structure that works:

Each design phase includes two rounds of revisions based on consolidated client feedback. A “round” is defined as one set of feedback collected from all stakeholders, delivered together, in writing or in a single feedback call. Revisions to address feedback delivered piecemeal (multiple emails, multiple stakeholders submitting at different times) may consume multiple rounds.

Revisions beyond the included rounds are billed at $X per hour, with estimates provided in advance.

Changes that fall outside the agreed scope (additional deliverables, deliverables in formats not listed in Section 2, deliverables for an audience or context not in the project overview) are change requests, not revisions. Change requests are scoped and quoted as separate engagements or addendums to this SOW.

Three things this language does, in order of importance.

It defines a “round.” Without that definition, every email with a revision request becomes its own round, the client uses up their three rounds in three emails, and now everything is billable. Defining rounds as “consolidated feedback” puts the burden of consolidation on the client, where it belongs.

It distinguishes revisions from change requests. A revision is “the wordmark feels too thin, can you try a heavier weight.” A change request is “actually, can we add a Spanish-language version of the brand guidelines?” Treating those as the same thing is how SOWs blow their budget.

It sets a price for additional revisions. Vague language like “additional revisions billed at standard rates” leads to negotiation when those revisions arrive. A specific dollar figure removes the negotiation.

Section 6: Payment terms

How much, when, and what happens if a payment is late.

Standard structure for a project under $20,000:

PAYMENT

Total project fee: $X,XXX

Payment schedule:
  - 50% deposit due before work begins
  - 50% due upon final delivery

Invoices:
  - Issued via [Stripe / PayPal / direct bank transfer / wire]
  - Net 7 from invoice date

Late payment:
  - Invoices unpaid 14 days past due date incur a 5% late fee
  - Work pauses on accounts more than 21 days overdue
  - Final files are not transferred until full payment is received

Currency: USD. Client is responsible for any wire fees, conversion
fees, or processing fees on their end.

Two clauses to call out specifically.

“Final files are not transferred until full payment is received.” This is the leverage that ensures payment. A client who has not paid does not get the source files. They get to see proofs. They get to review. They do not get production-ready assets until the wire clears. Industry-standard, accepted in most freelance design practice, worth stating explicitly.

The deposit clause. No design work should begin before the deposit is in the designer’s account. Not after the kickoff call, not after the contract is signed, not after the discovery brief is delivered. Deposit first, work second. Designers who skip this routinely end up doing two weeks of unpaid discovery work for clients who eventually disappear.

For larger projects, the structure changes — three or four payment milestones instead of two, tied to phase completion. The principles stay the same.

Section 7: Ownership and rights

Who owns what when the project ends.

The default that works for most freelance design engagements:

Upon receipt of full payment, all rights to the final deliverables transfer to the client. The designer retains the right to display the work in portfolio contexts (designer’s website, Behance, Dribbble, social media, design publications), reference the engagement publicly (case studies, talks, interviews), and use process artifacts (sketches, drafts, working files) as portfolio material.

The designer retains all rights to deliverables produced during the engagement that were not selected for final delivery (unselected logo directions, alternate color palettes, working drafts).

Stock photography, illustrations, fonts, and other third-party assets used in the deliverables are licensed under their respective terms; the designer transfers usage rights as permitted by those licenses.

A few notes.

The “portfolio rights” clause is non-trivial. Some clients — especially in legal, financial, or healthcare industries — will ask for it to be removed and the work kept confidential. That is a negotiation point. If a client wants confidentiality, the rate goes up to compensate, because the engagement loses its portfolio value.

The “unselected directions” clause prevents a client from later claiming ownership of a logo direction the designer made but the client did not pick. This matters when an unselected direction later resembles work the designer produces for a different client.

The third-party assets clause is the one that catches new freelance designers. If a designer uses a stock photo licensed for one project and the client uses the same image on a different campaign, the designer can be liable for the license breach if the SOW does not clarify which assets are subject to which license terms.

Section 8: Termination

What happens if either party wants to end the engagement before completion.

TERMINATION

Either party may terminate this engagement with 7 days written notice.

If terminated by the client:
  - All deposits and milestone payments to date are non-refundable
  - Designer retains the right to invoice for any work completed beyond
    paid milestones, calculated on a time basis at the rate stated above
  - Designer transfers files and assets in a state appropriate to the
    termination point, with no further obligations

If terminated by the designer:
  - Client may receive a refund of any unearned milestone payments
    (calculated as: paid amount minus designer's logged hours at the
    rate stated above)
  - Designer transfers any final deliverables completed and accepted

Termination does not waive any payment obligations accrued before the
notice date.

The asymmetry in those two paragraphs is intentional. A client terminating mid-project does not get refunded for work already completed, because the designer’s calendar was committed and that time cannot be reclaimed. A designer terminating mid-project owes a fair accounting back, because the client did not cause the work stoppage.

This is the section most likely to never get used and the section most expensive to leave out. Roughly one in twenty freelance design engagements ends in early termination. When it happens, the SOW is the only thing standing between a normal off-ramp and a payment dispute that takes months to resolve.

Putting the SOW into practice

Three operational tips for actually using SOWs as a freelance designer.

Build it as a template, not a from-scratch document. Every project’s SOW is 80% identical to every other project’s SOW. The first time a designer writes one, it takes three to four hours. After that, each new project’s SOW should take 20 to 30 minutes — fill in the project overview, customize the deliverables list, adjust the timeline, send.

Send it before the deposit invoice. The order is: discovery call → SOW sent → SOW signed → deposit invoice → deposit paid → work begins. Not: deposit invoice → SOW as an afterthought. The SOW is the artifact the deposit is paying against.

Use it as a project reference, not just a contract. After the SOW is signed, link to it from the project’s task tracker. When scope ambiguity comes up mid-project, the designer should be able to open the SOW in two clicks. In FoxWork OS, the SOW page template lives directly inside the Proposals & SOWs database, attached to the project record, viewable alongside its tasks and invoices. The exact tool does not matter; the principle does — the SOW should be a live reference, not a buried PDF in the client’s email archive.

A signed SOW does not guarantee a smooth project. It guarantees a defensible answer when something goes wrong. For most freelance designers, that is the difference between a profitable year and a year of working harder for less money.