A US client messages you: "Can you build a simple website for my coaching business? Budget is $400." You say yes. Three weeks later, the "simple website" has grown to eleven pages, a booking system, a blog migration and "just a few small logo tweaks". The client still thinks $400 covers all of it.
A statement of work (SOW) is the document that stops this. It's a short written description of exactly what you will deliver, by when, for how much, and what counts as finished. This guide shows you how to write one, even if the client never asks for it.
What a statement of work is, and how it differs from a contract
A contract or service agreement covers the legal frame: who owns the work, confidentiality, termination, liability and governing law. A SOW covers the practical detail of one specific project. Many clients use a single master agreement and attach a new SOW for each job.
If you only have a chat thread and no formal contract, a clear SOW is still the best protection you can build quickly. For the legal side, read our guide to reading a remote service agreement clause by clause, then use the SOW for the project detail.
Note that a SOW is not a substitute for legal advice. For large or long contracts, have a licensed lawyer read the agreement before you sign.
The seven parts of a useful SOW
Keep it to one or two pages. Clients read short documents; they skim long ones and then claim they never saw the details.
- Project summary. Two or three sentences on the goal. Example: "Design and build a five-page website for a coaching business, using the client's existing logo and text."
- Deliverables. A list of the actual things you hand over. Be specific: "5 pages: Home, About, Services, Contact, Booking link page", not "a website".
- Out of scope. What you are not doing. This is the most skipped section and the most valuable.
- Timeline and milestones. Dates or day counts for each stage, tied to what you need from the client.
- Client responsibilities. What they must provide and when: text, images, logins, feedback.
- Revisions and acceptance. How many rounds of changes are included and how the client confirms the work is done.
- Price and payment terms. Total, currency, milestones, due dates and what happens to extra work.
Step by step: turning a vague request into a scope
1. Ask questions before you quote
Vague requests hide extra work. Before naming a price, send a short list of questions. For a website: How many pages? Who writes the text? Do you have a logo and brand colours? Which platform? Who handles hosting? Do you need a contact form, payments or bookings?
Clients often respond with more detail than they first gave. That detail is what you price.
2. Write deliverables as nouns you can count
Good deliverables can be counted or checked: "8 blog posts of 800-1,000 words", "1 logo with 2 revisions", "weekly report in PDF". Weak ones use words like "support", "help with" or "manage" with no limit. If you must use them, attach a limit: "up to 5 hours of support per week".
3. List what is out of scope
Think about what the client might assume is included, then write it down. "Not included: writing website text, product photography, SEO work, hosting costs, changes to the site after final approval." You aren't being difficult. You're saving both sides an argument later.
4. Tie the timeline to the client's inputs
Remote projects stall most often because the client goes quiet. Write the timeline as dependent: "Draft delivered 7 working days after receiving text, images and login access." If they are late, your deadline moves with them. Without this line, you carry the blame for their delay.
5. Define revisions and "done"
Say how many revision rounds are included, how long the client has to respond (for example, 5 working days) and what counts as a revision versus new work. Changing a colour is a revision. Adding a new page is not.
Add an acceptance rule: "If no feedback is received within 5 working days of delivery, the deliverable is considered accepted." This prevents projects from hanging open indefinitely while you wait for final payment.
6. Split payment into milestones
For new clients, avoid payment only at the end. A common structure is a deposit before you start, a middle payment at a defined milestone and a final payment on delivery. The exact split is a negotiation. What matters is that you aren't doing all the work on trust. Check your payment channel options in our fee checklist for receiving dollars before you fix the currency and method in the SOW.
7. Add a change process
Write one sentence: "Work outside this scope will be quoted separately and started only after written approval." Then follow it. When a client asks for a new feature, reply: "Happy to add that. It's outside the current scope, so it would be an extra $X and Y days. Shall I proceed?"
A worked example (hypothetical numbers)
Imagine you're a content writer in Lagos and a UK software startup wants "blog content for our product". Here is a condensed SOW.
Project: Write 6 blog posts about accounting software for small businesses.
Deliverables: 6 posts, 1,000-1,200 words each, delivered as Google Docs with headings and a meta description.
Out of scope: Images, publishing to the website, keyword research (client provides keywords), social media posts.
Timeline: 2 posts per week, starting 3 working days after receiving keywords and the style guide.
Revisions: 1 round per post, requested within 5 working days of delivery. Further rounds at $15 per post.
Price: $60 per post, $360 total in USD. 50% ($180) before starting, 50% after the sixth post is delivered or accepted.
Extra work: Quoted and approved in writing first.
Now suppose after post three the client asks you to also create LinkedIn posts for each article. Without a SOW, you'd probably just do it. With one, you reply that social posts are outside scope and offer a price, say $10 each. If it takes you 30 minutes per post, that's a fair extra, and the client decides with full information.
How to pitch a SOW without sounding rigid
Some freelancers fear that asking for written scope will scare clients away. Usually it does the opposite; serious clients like clarity. Try framing it as a confirmation:
"Thanks for the call. To make sure we're aligned, I've put what we discussed into a one-page scope with deliverables, timeline and payment. Please check it and tell me if anything is missing, then I'll send the first invoice."
If the client already has their own SOW template, read it carefully for the same seven parts. Missing "out of scope" and revision limits are the usual gaps. Ask politely to add them.
Common mistakes
- Scoping by hours without a cap. "Hourly as needed" with no estimate lets the client lose control of the budget and then blame you for the bill. Give an estimate range and agree to alert them at a limit.
- Agreeing scope on a call only. Verbal agreements fade. Send a written recap the same day.
- Unlimited revisions. This turns a fixed price into an unpaid job that never ends.
- No client deadlines. If only you have deadlines, only you can miss them.
- Vague acceptance. If "done" is not defined, final payment can be delayed forever.
- Forgetting currency and fees. State the currency, who pays transfer or platform charges and the invoice due date.
- Not saving the signed or accepted version. Keep a copy of the final scope, and the client's "approved" reply, in a folder with your invoices.
How the approach changes by situation
| Situation | What to adjust |
|---|---|
| Small one-off gig on a freelance platform | Use the platform's offer or milestone feature, and put deliverables and revisions in the offer description. Check the platform's own rules on disputes. |
| Ongoing monthly retainer | Define hours or output per month, response times, and what happens to unused hours. Add a notice period for ending the arrangement. |
| Technical or software project | Add acceptance tests, such as "form sends email to client's address", and say who owns hosting accounts and logins. |
| Client with a big company | Expect their template. Focus on getting scope, acceptance and payment timing right, and note who your day-to-day contact is. |
| First project with a new client | Keep the first scope small, take a deposit and prove the relationship before agreeing to larger work. |
This applies the same way whether you're in Nigeria, Ghana, Kenya or South Africa, because it's about project clarity rather than local law. The legal enforceability of any agreement, and tax treatment of your income, differ by country, so check with a licensed adviser in yours.
Keep the paper trail while you work
A good SOW works best alongside records. Keep your work log matched to the deliverables, and make sure your invoices refer to the SOW milestones they relate to. If a payment dispute comes up, you can point to the agreed scope, the delivery date and the approval message.
Frequently asked questions
Does a SOW need to be signed?
A signature is better, but an email reply saying "Approved, please go ahead" is a useful record. Save it. For bigger projects, use a signature tool or ask the client to sign.
What if the client refuses to put anything in writing?
Send your own recap by email and ask them to reply "confirmed". If they won't even do that, treat it as a warning sign, take larger upfront payment or walk away from big work.
Can I change the scope mid-project?
Yes, if both sides agree in writing. Send a short update stating what changed, the new price and the new timeline, and get a reply before you proceed.
How long should a SOW be?
One page for small jobs, two or three for complex ones. If it's longer, you're probably copying legal text that belongs in the main agreement.
Your next step
Open your current or most recent project and write its SOW in the seven parts above, even after the fact. Spot the gaps, such as missing revision limits or an unclear "done", and fix them in your template for the next client.
Always apply through the employer's official website or verified channels. Genuine employers never ask applicants to pay for a job, training, or an interview.