How to Write a Scope of Work (Step-by-Step Guide)
Learn how to write a scope of work in 7 steps. Covers deliverables, timelines, budgets, revisions and sign-off with real examples for freelancers.
How to Write a Scope of Work (Step-by-Step Guide)
A scope of work is the single most important document in any freelance project. It defines what you will deliver, when you will deliver it, how much it costs, and what happens when things change. Without one, you are relying on memory, email threads, and good intentions — none of which hold up when a project goes sideways.
This guide walks you through writing a scope of work in 7 steps, with real examples and practical advice that applies whether you are a web designer, copywriter, graphic designer, marketing agency, or software developer.
If you are new to the concept, start with our guide on what a scope of work is before diving into the how.
Before You Start Writing
Before opening a blank document, you need information. A scope of work cannot be written in isolation — it is built from conversations with the client.
Information you need before writing:
- What problem does the client need solved?
- What does success look like to them?
- What is their budget (or budget range)?
- What is their deadline?
- Who will be the decision-maker for approvals?
- What do they expect to provide (content, assets, access)?
- Have they done this type of project before?
Gather this through a discovery call, a questionnaire, or both. The more thorough your discovery, the more accurate your SOW.
Step 1: Define the Project
Start with a clear, concise description of what the project is and why it exists.
This is not a detailed feature list — that comes later. This is the “elevator pitch” for the project that both you and the client can agree on.
Bad project definition: “Design and develop a website.”
Good project definition: “Design and develop a 12-page marketing website for [Client], a commercial cleaning company based in Reading, UK. The website will showcase the company’s services, display customer testimonials, and generate enquiries through a contact form. It will be built on WordPress and optimised for local search visibility.”
A good project definition answers:
- What is being created?
- Who is it for?
- Why does it need to exist?
- What platform will it use?
- What is the primary goal of the finished product?
Set Boundaries Early
Equally important is stating what the project does not include. This prevents assumptions.
“This project does not include: e-commerce functionality, blog content writing, ongoing SEO services, social media account setup, or email marketing integration.”
The exclusion list is not about being difficult. It is about being clear. Clients often assume that “a website” includes everything they have ever seen on a website. Your SOW tells them exactly which parts are included in their budget.
Step 2: List All Deliverables
A deliverable is a tangible output that the client receives. Be exhaustive and specific.
Vague deliverables (bad):
- Website design
- Content
- SEO
Specific deliverables (good):
- Wireframe mockups for 5 unique page layouts (PDF format)
- Visual design mockups for homepage, services page, and about page (Figma link)
- WordPress development of 12 pages (see sitemap in Section 3)
- Contact form with email notifications to [client email]
- Google Analytics 4 installation and configuration
- On-page SEO for all 12 pages (meta titles, descriptions, header structure)
- 30-minute training video on how to edit WordPress content
Each deliverable should pass the “could I check this off a list?” test. “Website design” is too vague to check off. “Visual design mockups for 3 pages” is concrete and verifiable.
Quantify Everything
Numbers eliminate arguments:
- Not “blog posts” but “4 blog posts, 1,500-2,000 words each”
- Not “social media graphics” but “12 Instagram post graphics, 1080x1080px”
- Not “revisions” but “2 rounds of revisions per deliverable”
- Not “support” but “30 days of post-launch bug support”
Separate Must-Haves from Nice-to-Haves
If the project has a fixed budget, prioritise deliverables:
- Must have: Required for the project to be considered complete
- Should have: Important but can be added after launch
- Nice to have: Desirable but only if budget and timeline allow
This gives both parties a clear framework for making trade-offs if the project needs to be descoped.
Step 3: Set the Timeline
Break the project into phases with dates and milestones.
A timeline does two things: it commits you to delivering on schedule, and it commits the client to providing feedback on schedule. Both commitments matter equally.
Example timeline for a web design project:
| Phase | Duration | Your Deliverable | Client Action | Deadline |
|---|---|---|---|---|
| Discovery | Week 1 | Creative brief | Complete questionnaire | 7 Mar |
| Wireframes | Weeks 2-3 | Wireframe mockups | Review and approve | 21 Mar |
| Design | Weeks 4-5 | Visual mockups | Review and approve | 4 Apr |
| Development | Weeks 6-8 | Staging site | Review and test | 25 Apr |
| Launch | Week 9 | Live site | Final sign-off | 2 May |
Build in Client Response Time
Every phase that requires client approval should have a stated response window:
“Client feedback is expected within 5 business days of each deliverable submission. Delays in client feedback will extend the project timeline by an equivalent duration.”
This clause is not aggressive — it is fair. If you deliver wireframes on Monday and the client does not review them for three weeks, the project is three weeks behind. That delay should not compress your development timeline.
Account for Dependencies
Some tasks depend on others. Make these dependencies visible:
“Development cannot begin until design mockups are approved. Content population cannot begin until all client content is received.”
If the client delays content delivery, they need to understand that it directly delays the project.
Step 4: Define the Budget and Payment Schedule
State the total project fee and break it into payment milestones.
Payment Milestone Options
Percentage-based (most common for freelancers):
- 50% deposit at project start
- 25% on design approval
- 25% on launch
Phase-based:
- £1,000 on signing (deposit)
- £2,000 on wireframe completion
- £2,500 on design approval
- £2,500 on launch
Monthly (for retainers):
- £3,000 per month, invoiced on the 1st
- Minimum 3-month commitment
What to Include in Budget Terms
- Total project fee
- Payment schedule with triggers (what event triggers each payment)
- Payment method (bank transfer, Stripe, PayPal)
- Payment terms (due within 14 days of invoice)
- Late payment fee (e.g., 2% per month on overdue amounts)
- Deposit refund policy (typically non-refundable)
- Kill fee (what the client owes if they cancel mid-project)
Rate for Additional Work
State what happens when the client requests work beyond the SOW:
“Additional work not described in this SOW will be quoted at £[X]/hour. A written quote must be approved by the client before additional work begins.”
This connects your SOW to your invoicing process.
Step 5: Specify the Revision Process
Revisions are where scope creep lives. Without a defined process, every piece of feedback becomes a free revision.
Define Revision Rounds
- How many revision rounds are included (2-3 is standard)
- What constitutes one round (all feedback submitted at once, not drip-fed)
- Turnaround time for revisions (e.g., 3 business days)
- What happens after included rounds are used (hourly rate for additional revisions)
Define What a Revision Is
This is critical:
- A revision changes existing elements within the agreed scope (e.g., “change the headline from X to Y,” “swap the blue for green”)
- A new direction fundamentally changes the concept or approach (e.g., “actually, I want a completely different layout”)
- New scope adds deliverables not in the original SOW (e.g., “can you add a blog section?”)
Revisions are included. New directions may require restarting a phase. New scope requires a change request with additional budget.
Feedback Format
State how you want to receive feedback:
“Feedback should be submitted as a single consolidated document (email, shared doc, or annotated PDF). Verbal feedback will not be actioned — it must be documented in writing.”
This prevents the “I told you on the call” problem where neither party can verify what was actually agreed.
Step 6: Add Terms and Conditions
Your SOW needs standard terms to protect both parties:
Ownership and IP
- What the client owns upon full payment (typically everything custom-built)
- What you retain (portfolio rights, general-purpose code/templates)
- Third-party assets (stock images, fonts, plugins — licensed, not owned)
- What happens to ownership if the project is cancelled or payment is not received
Confidentiality
- Both parties agree to keep project details confidential
- You may display the finished work in your portfolio (unless the client requests otherwise)
Cancellation
- Deposit is non-refundable
- Cancellation after [phase] incurs a fee of [amount or percentage]
- All completed work is billed at your hourly rate
Liability
- Your liability is limited to the project fee
- You are not liable for lost revenue, lost data, or third-party issues
Change Requests
- Changes beyond the SOW require a written request
- You provide a quote within [X] business days
- Client approves in writing before work begins
- Changes are invoiced separately
Step 7: Get Sign-Off
A SOW that is not signed is just a proposal. Both parties need to sign and date the document.
Signature Process
For simple projects:
- PDF with signature lines
- DocuSign or similar e-signature
- Email confirmation (“I confirm that I agree to the SOW dated [date] and attached to this email”)
For larger projects:
- Formal digital signature via DocuSign, HelloSign, or PandaDoc
- Signed by authorised representatives on both sides
- Countersigned copy returned to both parties
What to Do After Signing
- Save a signed copy for your records
- Send the client a signed copy for their records
- Send the deposit invoice referencing the SOW number
- Begin work only after the deposit is received
- Reference the SOW number on all subsequent invoices and correspondence
Real-World SOW Example: Walkthrough
Here is how the 7 steps come together for a real project — a freelance graphic designer hired to create a brand identity:
Step 1 (Project): “Create a brand identity package for [Client], a new coffee subscription service, including logo, colour palette, typography, and brand guidelines document.”
Step 2 (Deliverables):
- 3 initial logo concepts
- Selected logo refined through 2 revision rounds
- Logo files in AI, SVG, PNG, JPG (full colour, black, white, icon-only)
- Colour palette (primary, secondary, accent) with hex, RGB, and CMYK values
- Typography selection (primary and secondary typefaces)
- Brand guidelines PDF (20-page document)
Step 3 (Timeline):
- Week 1: Brief and research
- Weeks 2-3: Logo concepts
- Week 4: Concept selection and refinement
- Week 5: Brand guidelines document
- Week 6: Final delivery
Step 4 (Budget): £3,500 total. 50% deposit (£1,750), 50% on delivery (£1,750).
Step 5 (Revisions): 2 rounds included. Additional rounds at £85/hour. Feedback due within 5 business days.
Step 6 (Terms): Full ownership transfers on payment. Designer retains portfolio rights. Cancellation after concept stage incurs 50% of remaining fee.
Step 7 (Sign-off): Signed via DocuSign. Deposit invoiced same day.
Common Mistakes When Writing a SOW
Writing it after starting work. The SOW should be signed before any work begins. Writing it retroactively means you are documenting what you hope happened, not what was agreed.
Being vague to win the project. Vagueness feels safe because it does not commit you to anything specific. But it also does not commit the client. The project will expand to fill the vagueness, and you will do more work than you were paid for.
Not including exclusions. What you are not doing is as important as what you are doing. List it.
Skipping the revision policy. Every project needs a revision cap. Without one, revisions are infinite and free. That is not sustainable.
Making it too long. A SOW should be comprehensive but readable. If it is 30 pages for a £2,000 project, you have over-engineered it. Match the document’s complexity to the project’s complexity.
Not getting it signed. A SOW sitting in someone’s inbox is not an agreement. It is a suggestion. Follow up. Get the signature. Then start.
Next Steps
Now that you know how to write a scope of work, explore our industry-specific templates:
- Web design SOW template
- Marketing agency SOW template
- Graphic design SOW template
- Copywriting SOW template
- Software development SOW template
For real examples you can reference, see our 10 scope of work examples across different industries.
When your SOW is signed and the work begins, you will need to invoice based on the milestones you defined. Each invoice should reference the SOW number, creating a clean paper trail from agreement to payment.