Most freelance projects that go wrong did not go wrong at the end. They went wrong at the start, in a conversation where both people used the same word to mean two different things.
"A website." "A brand identity." "Social media creatives for the launch." Each of those describes a range of work so wide that the same sentence can mean three weeks or three months. A scope of work is the page where you close that range before anyone starts.
Scope of work is not the contract
They get used interchangeably and they do different jobs.
The contract covers the relationship: payment terms, ownership of the work, confidentiality, what happens if either side walks away. It is largely the same document from project to project.
The scope of work covers this project: what you are making, how many of them, how many rounds of changes, what you need from the client and when, and what is explicitly not included. It changes every time.
You can put the scope inside the contract as a section, and for small projects that is usually the right move. What you should not do is have a contract with no scope in it, which is the common failure. A contract that says "design services as agreed" has not agreed anything, and it will not help you in the argument you are actually going to have. If you need the surrounding document, freelance contract template covers it, and contract versus invoice covers which document does what.
The six sections that do the work
1. Deliverables, as countable things. Not "social media creatives" but "12 static posts and 4 story frames, sized for Instagram, supplied as PNG and as editable source files". If it cannot be counted, it cannot be finished, and a project that cannot be finished is one you are still doing in November.
2. Revision rounds, with a number. Two rounds is standard for most creative work. Say what a round is: one consolidated set of feedback from the client, not a trickle of individual messages over nine days. Then say what happens after the included rounds are used, with a rate. The rate is the part people leave out, and without it the answer to "can we just try one more version" is always yes.
3. What you need from the client, and by when. Copy, logos, product photos, access to accounts, a decision-maker who is available. This is the clause that protects your timeline. If a project slips four weeks because brand assets arrived four weeks late, you want that written as a dependency rather than remembered as you being slow.
4. Timeline, tied to dependencies. Give durations from a trigger rather than fixed dates: "first concepts within 7 working days of receiving brand assets and the completed brief". Fixed calendar dates transfer every client delay onto you.
5. Exclusions, written plainly. The most valuable section and the one that feels rudest to write. Hosting, copywriting, printing, ongoing maintenance, stock licences, the second language version. Anything a reasonable client might assume is included but is not. Three lines here prevent the conversation where someone says "I assumed that was part of it", and they are not lying, they genuinely did assume.
6. Change process. What happens when the scope moves, because it will. Something as short as: work outside this scope is quoted separately and starts once approved. That sentence converts scope creep from a favour into a quotation, which is the entire point. I have written about handling scope creep once it has already started, but the cheapest version is preventing it here.
A scope of work template you can lift
| Section | One line on what to write |
|---|---|
| Project | One sentence on the outcome, in the client's language |
| Deliverables | Countable items, with formats and quantities |
| Not included | The assumptions you are ruling out |
| Revisions | Number of rounds, what a round is, rate after |
| Client inputs | What you need, and the date you need it by |
| Timeline | Durations from triggers, not fixed dates |
| Change process | One sentence: out of scope is quoted separately |
| Acceptance | What counts as approved, and how long they have to say so |
The acceptance row is worth a moment. Without it, "done" is a feeling rather than an event, and the project never formally ends. Something like: deliverables are treated as accepted if no consolidated feedback arrives within 7 working days. It sounds bureaucratic and it is the difference between a project that closes and one that lingers into next quarter.
Screenshot the request
The change process only works if you can show what was asked for, and months later nobody remembers who said what in which thread.
The move that works is mechanical. When a client asks for something new mid-project, screenshot the message and paste it into the scope of work as a new line: change request, plus this much, plus this many days. You are not arguing, you are filing. If they later push back on the extra charge, you send the screenshot back, and the conversation ends there almost every time.
This matters more on Indian freelance projects than the templates suggest, because most client communication happens on WhatsApp, not email, where nothing is threaded and nothing is searchable six weeks later. A scope of work that lives beside those messages, and gets amended from them, is the only version of a paper trail that survives how people actually work. Freelancing without one is like writing code without version control: fine until the day it is not.
For studio and small-team projects
If you work with collaborators, two extra lines earn their space.
Name who is doing what. Not for the client's benefit exactly, but because a scope that assumes a specific person is available becomes a different scope when they are not.
Say who gives feedback. Consolidated feedback from one named person. The single largest cause of revision overrun on larger projects is three stakeholders sending contradictory notes directly, and then the reconciliation becoming your job for free.
Where the document should live
Write it once, reuse the structure, change the specifics. Six sections is a page, and a page is the point. This does not need to be a legal document to work. What we agreed, what it costs, what is not included, sign at the bottom. Send it over WhatsApp as a PDF before the work starts, and the argument you are avoiding is the one in month three, when neither of you remembers what was actually agreed.
Trying to write it fresh for every project is why people skip it, and skipping it on the small projects is a mistake: the small ones are where scope creeps furthest, because nobody thought it was worth the paperwork.
Riffit's contracts keep the scope inside the document, not in an attachment that drifts away from it. You build it on the dashboard, where there is room for scope and terms, and your client signs from their phone with a six-digit code sent to them. A signed contract carries an audit trail recording who signed, when, and the timeline of events leading to it, so the agreed version and the agreement itself stay attached to each other.
Once it is signed, that contract turns into an invoice without you retyping the client, the project title or the amount, either from the dashboard or by asking for it in WhatsApp. The invoice comes across as a single line; the scope stays where it belongs, on the signed document. Contracts are free for your first 3, then unlimited on Pro at ₹249/month, or ₹199/month billed annually. Every signup starts on a 14-day Pro trial.
None of this makes the document do legal work. What it does is make sure that in March you can still find the version you actually agreed to. That is the practical problem most freelancers have. For anything with real money or real risk attached, have a lawyer read your standard terms once.
Put the scope in the contract, send it for signature, and turn it into an invoice when it is signed.Try Riffit freeFAQ
It is the document that defines what you are making on this specific project: the countable deliverables, the number of revision rounds, what you need from the client and when, the timeline, what is excluded, and how changes get handled. It is project-specific, unlike the contract, which covers the relationship and stays broadly the same each time.