How to Write a Scope of Work

A scope of work (SOW) is a document that defines exactly what will be delivered as part of a project, along with timelines, responsibilities, and boundaries. It is the single most important document for preventing misunderstandings between you and your client.

Without a clear scope of work, you are vulnerable to scope creep — the gradual expansion of project requirements beyond what was originally agreed. Scope creep is the number one profit killer for freelancers. It starts innocently: "Can you just add one more page?" or "While you are at it, could you also do X?" Each small request seems reasonable in isolation, but together they can double your workload without increasing your fee.

A well-written SOW protects both parties. It gives the client confidence that they know exactly what they are getting and when. It gives you a reference point to push back on requests that fall outside the agreed work. And if a dispute arises, the SOW is the document that resolves it.

The scope of work is typically included within your business proposal or attached as a separate document alongside a contract. For smaller projects, the scope section of your proposal may be sufficient. For larger or longer projects, a standalone SOW is worth the extra effort.

A complete scope of work should cover the following elements. You can adapt the level of detail to match the project size — a £500 project does not need a 10-page SOW, but it still needs clear deliverables and boundaries.

Project overview: A brief summary of the project goals and context. One or two paragraphs that describe what the project is about and what success looks like. This ensures everyone is aligned on the purpose before diving into specifics.

Deliverables: The most important section. List every tangible output the client will receive. Be specific: not "website design" but "Homepage design (desktop and mobile), About page design, Services page design, Contact page with form, Blog listing page — all delivered as Figma files and exported as production-ready assets." If it is not on the list, it is not included.

Timeline and milestones: Break the project into phases with dates. For example: "Week 1–2: Research and wireframes. Week 3–4: Design concepts (two options). Week 5: Revisions and final delivery." Include any dependencies — for example, "Design phase begins within three business days of receiving brand guidelines from client."

Client responsibilities: What does the client need to provide, and by when? Content, images, access credentials, feedback, approvals — list everything. Make it clear that delays on the client's side may push back the timeline.

Out of scope: Explicitly state what is NOT included. This is just as important as listing what is included. If you are designing a website but not writing the copy, say so. If you are building a logo but not creating a full brand identity, say so. The out-of-scope section prevents assumptions.

Revisions are a natural part of any creative or professional project, but unlimited revisions are a trap. Without clear limits, clients can request round after round of changes, effectively turning a profitable project into free labour. Setting revision limits is not about being difficult — it is about establishing professional boundaries that lead to better outcomes for everyone.

How many revisions to include: Two to three rounds of revisions is standard across most industries. A "round" means the client collects all their feedback and sends it to you in one batch, and you implement those changes. This is different from a continuous drip of individual requests, which should be discouraged.

Define what counts as a revision: Be clear about the distinction between a revision (a change to the agreed deliverable) and a new request (additional work outside the original scope). For example, "Change the heading colour from blue to green" is a revision. "Add a completely new section we did not discuss" is additional scope and should be quoted separately.

How to handle additional revisions: State in your SOW that revisions beyond the included rounds will be charged at your hourly rate (e.g. £50/hour). This creates a natural incentive for the client to consolidate their feedback and make decisions, rather than using you as a sounding board for endless iterations.

Framing revision limits positively: Rather than presenting limits as a restriction, frame them as part of a structured process: "This project includes two rounds of revisions to ensure we arrive at a final result you are delighted with. If additional changes are needed beyond these rounds, they can be accommodated at [hourly rate]." This sounds collaborative, not adversarial. Pair revision limits with a clear pricing structure so the client understands the full picture.

Even with a detailed scope of work, clients will sometimes request changes during a project. The question is not whether this will happen, but how you handle it when it does. A change order process gives you a professional framework for saying yes to new requests without absorbing the cost.

What is a change order? A change order is a documented request to add, remove, or modify deliverables outside the original scope of work. It includes a description of the change, the impact on the timeline, and the additional cost. Both parties must agree before the work proceeds.

When to use a change order:

• The client wants to add a deliverable that was not in the original SOW
• The client wants to significantly alter an already-approved deliverable
• New information emerges that changes the project requirements
• The client's delays have pushed the timeline beyond the original plan and require rescheduling

How to raise it with the client: Keep it straightforward: "That is a great idea. It falls outside our current scope, so let me put together a quick change order with the additional cost and timeline impact. Once you approve it, I will add it to the project." This is professional, not confrontational. Most clients respect clear boundaries because it shows you manage projects carefully.

Include change order terms in your SOW: Add a clause like: "Any changes to the deliverables, timeline, or scope described in this document will be managed through a change order process. Changes will be quoted separately and require written approval before work begins." This sets the expectation from day one and means you never have to introduce the concept mid-project when tensions may be higher.

A clear sign-off process prevents one of the most frustrating scenarios in freelancing: the project that never ends. Without defined approval milestones, clients can keep requesting changes indefinitely, and you have no clear point at which the project is "done."

Build approval milestones into your SOW: At key stages of the project, require formal client approval before moving to the next phase. For example:

1. Brief sign-off: Client confirms the brief and project requirements before work begins.
2. Concept approval: Client approves the initial concept or direction (e.g. wireframes, draft outline, design concept).
3. Revision sign-off: After each revision round, client confirms the changes are acceptable.
4. Final delivery sign-off: Client confirms the project is complete and all deliverables meet the agreed requirements.

What "approval" means: Define this in your SOW. A simple approach: "Approval is confirmed by written response (email or message) within five business days of delivery. If no response is received within five business days, the deliverable is deemed approved." This prevents clients from leaving you in limbo indefinitely.

What happens after final sign-off: State that any changes requested after final delivery sign-off constitute new work and will be quoted separately. This protects you from the client who approves everything, then comes back three weeks later with a list of changes they "forgot" to mention.

Payment linked to milestones: For larger projects, tie payment instalments to sign-off milestones. For example: 30% on brief sign-off, 30% on concept approval, 40% on final delivery. This ensures you are paid progressively as work is approved and reduces the risk of non-payment at the end of a project. Include these payment terms in your proposal alongside the scope — see our guide to writing winning proposals for how to structure this.

Use this template structure as a starting point for your own scope of work documents. Adapt the level of detail to match the project complexity and value.

Section 1 — Project overview: Two to three sentences describing the project purpose, the client's goals, and the expected outcome. Keep it high-level.

Section 2 — Deliverables: A numbered list of every tangible output. For each deliverable, include the format (e.g. PDF, Figma file, WordPress page) and any specifications (e.g. word count, dimensions, responsive breakpoints).

Section 3 — Timeline: A table or list of phases with start dates, end dates, and the deliverables associated with each phase. Note any client dependencies that could affect the timeline.

Section 4 — Client responsibilities: Everything the client needs to provide, with deadlines. Content, assets, access, feedback windows, and approval turnaround times.

Section 5 — Revisions: Number of revision rounds included, what constitutes a round, and the rate for additional revisions.

Section 6 — Out of scope: A clear list of what is not included. Be specific about common assumptions that clients make in your industry.

Section 7 — Change order process: How out-of-scope requests will be handled, including quoting and approval steps.

Section 8 — Approval and sign-off: The milestone approval process and what happens after final sign-off.

Section 9 — Payment terms: Total fee, payment schedule (linked to milestones if applicable), payment method, and late payment terms.

Quick checklist before sending your SOW:

• Every deliverable is specific and measurable
• Timeline includes realistic buffers for feedback and revisions
• Client responsibilities are clearly stated with deadlines
• Out-of-scope items are listed to prevent assumptions
• Revision limits are defined and priced
• Sign-off process is documented
• Payment terms are clear and linked to milestones

OwnedWork's proposal builder includes a scope of work section that follows this structure automatically, helping you create professional SOW documents without starting from scratch every time.