You agreed on the project verbally, the client seemed clear on what they wanted, and you started work. Three weeks in, they’re asking for features you never discussed, changes to work you already completed, and a deadline you didn’t agree to. You have no document to point back to. A scope of work would have prevented all of it, and writing one takes less time than the average scope creep conversation.
We reviewed project management guidance from the Freelancers Union, practical templates from Bonsai and HoneyBook, and experiences shared in freelancer communities across multiple disciplines, including design, writing, development, and consulting. We focused on what professional freelancers actually include in their scopes of work and how those documents hold up when client relationships get complicated.
In this article, we’ll walk you through how to write a scope of work for a freelance project: what to include, how to structure it, where it fits alongside your contract, and how to use it as a working document throughout the engagement.
Step 1: Understand What a Scope of Work Is (and What It Isn’t)
A scope of work is a document that defines what you will deliver, when you will deliver it, and what falls outside the agreed project. It is a mutual reference point, not a legally binding contract on its own. Your scope of work describes the work; your contract creates the legal obligation. In practice, most freelancers attach the scope of work to their contract or incorporate it by reference so that both documents work together.
A scope of work is also different from a project brief. The project brief is the client’s description of what they need and why. Your scope of work is your documented response: here’s what you’ll produce, when you’ll produce it, and what’s not included. Writing the scope of work is your opportunity to translate a client’s potentially vague brief into specific, agreed-upon deliverables before any work begins.
Think of it this way: the project brief answers “what do you want?” and the scope of work answers “here’s exactly what you’ll get, by when, and what we’re not doing.” That second document is the one that protects both parties.
Step 2: Write a Clear Project Overview
Open the scope of work with a brief summary of the project: what it is, why it’s being done, and who the parties are. Two or three sentences establishing shared context are enough. For example: “This scope of work covers the design and delivery of five landing page templates for [Client Name]’s spring campaign. Templates will be delivered in Figma and optimized for desktop and mobile.”
Including a brief statement of the project’s purpose helps anchor decisions later in the engagement. When the client asks why certain elements aren’t included, you can refer back to the stated purpose. A clear overview also helps new contacts at the client’s organization understand what was agreed upon if your original point of contact changes mid-project, which happens more often than freelancers expect.
Step 3: List Your Deliverables Specifically
This is the most critical section of any scope of work. Vague deliverables are the primary source of scope creep and client disputes. For every deliverable, specify: what it is, what format it will be delivered in, and how many you’re providing.
A vague deliverable sounds like: “Website copy.” A specific deliverable sounds like: “Homepage copy (up to 400 words), About page copy (up to 300 words), and three service page descriptions (up to 250 words each), delivered as a Google Doc with comments enabled.” The difference is the difference between a project that ends cleanly and one that drags on.
Equally important is an explicit “Out of Scope” section listing related work you won’t be performing. For example: “This scope does not include social media copy, paid ad copy, or SEO keyword research.” Clients don’t always intend to expand scope; they frequently assume that adjacent tasks are included unless told otherwise in writing. A brief exclusions list prevents the most common form of unspoken expectation.
Step 4: Set a Timeline With Milestones
Rather than a single final deadline, break the project into milestone-based phases with discrete dates. This creates shared checkpoints and reduces the risk of a last-minute delivery that misses expectations after weeks of silence.
For a mid-size project, a typical milestone structure might be: project kickoff, first draft delivery, client review period (with a defined number of business days), revisions complete, and final delivery. Specifying how long the client has for each review cycle is particularly important. Open-ended review periods are one of the most common ways freelance timelines drift well beyond their original scope.
Be explicit about what your proposed dates assume. If the timeline depends on receiving assets, information, or feedback from the client by a certain date, state it directly. “Final delivery by April 15 assumes client feedback on the first draft is provided within five business days of delivery.” This creates a shared responsibility model rather than placing the entire timeline risk on your side.
Step 5: Define Your Revision Policy
A revision policy is one of the most underused tools in freelance project management, and one of the most effective at preventing scope creep. Your scope of work should state how many rounds of revisions are included in the quoted price, what constitutes a revision as opposed to a new deliverable, and what happens if revisions exceed the included amount.
A common structure is to include two rounds of revisions in your base quote and charge your hourly rate for anything beyond that. Some freelancers define the boundary explicitly: “A revision means a change to existing work. A revision does not include new sections, new research, or changes to the project’s core direction, which will be scoped and quoted separately.”
Revision policies feel awkward to introduce early in a relationship. In practice, however, clients who are genuinely aligned on the project scope rarely use all of their included revisions anyway. The policy exists primarily for situations where project requirements drift significantly, which is exactly the moment you need it most.
Step 6: Include Payment Terms and an Approval Process
Your scope of work should reference the payment structure, even if the full payment terms live in your contract. At minimum, note the total project fee, the deposit amount if any, and the due dates for each payment installment. This ensures the client reading the scope understands the commercial terms as well as the work terms.
An approval process is equally useful. Specify how deliverables are considered complete and accepted. For example: “Deliverables are considered approved if the client provides written sign-off or fails to provide feedback within five business days of delivery.” This prevents the common situation where you’ve submitted final work, the client hasn’t responded, and it’s unclear whether the project is closed or still open.
Both the payment terms and the approval process should be consistent with what’s in your freelance contract. Discrepancies between the two documents create confusion and can undermine both if there’s ever a formal dispute.
Step 7: Get It Signed Before You Start
A scope of work is only effective if both parties have agreed to it in writing. Ask the client to sign and return the document before you begin work. If you use a contract platform like Bonsai, HoneyBook, or DocuSign, you can embed the scope within the contract or send it as a co-signed attachment.
Some clients resist signing additional documents, particularly in fast-moving creative relationships. In those cases, request written confirmation via email that the scope is agreed upon. An email that says “I’ve reviewed the scope and we’re ready to proceed” creates a documented record of mutual agreement, even without a formal signature.
Freelance consultant and author Brennan Dunn, whose client management frameworks have been widely cited in freelancer communities, documented in his client guides that the single most predictable factor in whether a project ends with a strong client relationship is whether a clear written scope was agreed on before work began. In his survey data, projects with a signed scope had significantly lower rates of scope creep and payment disputes than those without one.
Do This Week
- Create a scope of work template with your standard sections: project overview, deliverables, out of scope, timeline with milestones, revision policy, payment terms, and approval process.
- Review your current or most recent active project. If you don’t have a scope of work document for it, write one retroactively and share it with the client as a “project alignment summary.”
- Add a revision policy to your standard template if you don’t have one. Decide how many rounds of revisions you’ll include by default and at what rate you’ll charge for additional rounds.
- The next time you send a proposal or quote, attach your completed scope of work template alongside it and ask for a written sign-off before the engagement begins.
- Audit your “out of scope” language. For each service you offer, list three to five adjacent tasks clients frequently assume are included, and add those explicitly to your exclusions section.
- If you use a contract platform, check whether its templates include a scope of work section and whether they support e-signature for that document.
- Review any projects from the past year that ran over budget or over time. Identify whether a clearer scope of work would have prevented the issue, and tighten your template accordingly.
- Share your scope of work template with a peer in your field and ask for feedback on anything that might read as ambiguous from a client’s perspective.
Final Thoughts
A scope of work doesn’t protect you from every difficult client situation, but it dramatically reduces the most common ones: expanding expectations, unclear deliverables, and payment disputes tied to “we never agreed on that.” The time you spend writing it before the project starts pays back many times over over the course of a career. Make it a routine part of your client onboarding, treat it as a working document rather than a formality, and refer back to it whenever the engagement starts drifting. When both you and the client can point to the same document, disagreements shrink to a fraction of what they’d otherwise be.
Photo by Aaron Burden; Unsplash
