How to Set Project Scope With Clients: Six Steps From First Call to Locked Baseline

Most advice about project scope stops at "be specific." That is true and it is not the problem. The problem is that specificity written into a document nobody opens again does no work at the moment it is needed — which is not during the kickoff call, it is eleven weeks later, on a phone, when a client asks for one more thing and you have four seconds to decide whether it is free.

So this guide treats scoping as something you do to a boundary, not to a document. Six steps, each one ending in something checkable.

Scope is a boundary you can point at

A scope has done its job when a request can be compared to it in under a minute, by you, without re-reading a contract. That is a higher bar than "we discussed it", and it is a different bar from "it is in the SOW".

Three properties get you there:

It is counted. Numbers are checkable. Adjectives are not.
It says what is out. Creep almost never arrives as something your deliverables list refused. It arrives as something nobody mentioned.
It is fixed at a version. If the agreed list can be quietly edited, it cannot settle an argument, because both parties will remember a different edition of it.

Everything below is in service of those three.

Step 1: Agree the outcome before the deliverables

Start with what the client is buying, not what you are making. A client who says "a five-page website" has told you the shape of the invoice; a client who says "we need restaurant bookings to stop going through Instagram DMs" has told you what the project is for — and that sentence is what tells you whether "add an online ordering flow" is a new deliverable or the thing they thought they were paying for all along.

Three questions do most of the work:

What has to be true when this is finished? One sentence. If they give you three, the project is probably two projects.
Who uses it, and what do they do first? This is where hidden deliverables surface — an admin screen, a training doc, a migration nobody costed.
How will you know it worked? Not to write a KPI clause. To find out whether they are expecting a result you cannot deliver alone.

Write the answers down and read them back in the same call. Misalignment discovered here is free. Discovered in week six, it costs a redesign.

Step 2: Count the deliverables, then write the exclusions

Convert the outcome into a list with numbers on it.

Included: 5 pages (Home, Menu, About, Contact, Order Info);
2 rounds of revisions per page; 1 responsive breakpoint set
(mobile / tablet / desktop); 1 handover call (60 min).

Then write the harder half. The exclusions list is the single highest-return section in any scope, because it is where you pre-answer the requests that are coming:

Not included: e-commerce or payment functionality; logo or brand work;
copywriting; photography; hosting or third-party subscription costs;
ongoing maintenance after handover; additional language versions.

Both lists belong in the document that gets signed. If you want the section-by-section version, the freelance statement of work template covers the eight parts that actually settle disputes, and contract clauses that prevent scope creep covers the language to use inside them.

Vague wording is hard to catch in your own draft, because you know what you meant. Stria's Scope Clarity Check reads a draft agreement before it goes for signature, quotes the exact sentence that will cause the argument, and suggests a tighter rewrite. You can run the same comparison on a pasted excerpt with no account at the free scope check — it stores nothing.

Step 3: Put a price on the next round, not the fifth

Revisions are where fixed-fee work stops being profitable, and it happens without anybody behaving badly. "Can we try a few more variations" is a reasonable sentence. It is also a round, and rounds are the unit your fee was built on.

The fix is arithmetic, agreed in advance:

Two rounds of revisions are included per deliverable. A round is one
consolidated set of feedback. Further rounds are billed at $[rate]/hr,
estimated and approved before work starts.

Two details make this hold. First, define a round as one consolidated list — otherwise five separate emails become five rounds in your head and one round in theirs. Second, name the rate now. A rate agreed while everyone is optimistic is a fact; a rate quoted in round four is a negotiation. How to charge for extra revisions has the wording for the conversation itself.

Step 4: Say when a deliverable is accepted

Most freelance projects have no defined end. Work is delivered, nothing formal happens, and the project stays open in the client's mind indefinitely — which is how a deliverable signed off in March reopens in July.

An acceptance window closes it:

Deliverables are accepted if no revision request is received within
10 business days of delivery.

This clause is only worth having if something actually watches the clock. In Stria, approval deadlines run as a mechanic rather than a sentence: a pending sign-off is chased with written notice, and silence past the window is recorded as approval on the delivered version rather than left to be argued about later.

Step 5: Agree the change route before you need it

Every scope will be tested. The question is whether the test arrives as an awkward conversation or as a form.

Work beyond the deliverables listed above requires a written change
order, priced and agreed in writing before the work begins.

One clause, and it changes the default. Without it, an out-of-scope request puts you in the position of asking for money mid-project — which is the real reason unpaid work gets absorbed. It is rarely a knowledge problem. You already know a sixth revision round is outside the agreement; what stops the change order being written is the ninety seconds of social discomfort between noticing and saying so. With the clause in place, you are not asking for anything. You are following the process you both signed.

Use the freelance change order template for the document, and how to price a scope creep request for the number that goes on it.

Step 6: Lock the list, then check requests against it

This is the step most scoping advice leaves out, and it is the one that converts a document into a boundary.

Locking means the agreed list is fixed at a version that cannot be quietly edited — only amended, with the amendment referencing what it changed. That is what makes it usable as evidence: both parties are looking at the same edition.

Then the boundary has to be consulted at the only moment that matters, which is before you reply. In Stria that is what forwarding is for. You send the client's email to your Stria address and get the request compared against the scope you locked, with the clause it falls outside quoted back at you and a price built from your rate card — before you answer. It does not connect to your inbox; you choose what to forward, and you approve what goes out. Where there is no rate card to price against, or the request is too vague to size, it says so and shows the basis rather than inventing a figure.

From there, a finding becomes a change order in one step, and the client's approval is recorded with a content hash, a timestamp and the version it applies to — so the thing you can produce in six months is a record, not a screenshot hunt.

Detection is on the free plan. Start a 14-day Stria trial if you want it running against your own projects, or try the scope check first with no account. What Stria does to a client request walks the whole path, including the three things it deliberately will not do.

What this looks like when it fails

Worth naming, because the failure has a signature. A scope fails quietly when:

The deliverables list uses adjectives. "A modern, polished homepage" cannot be compared to anything.
There is no exclusions section, so every unmentioned thing is arguably included.
Revisions are described without a number, or numbered without a rate for the round after.
The signed version lives in an email attachment, so nobody is certain which edition is current.
Nobody looks at it. This is the most common failure by a distance, and it is the one that has nothing to do with how well the scope was written.

If your last three projects each grew by a day or two of unbilled work, the odds are the scope was fine and step six was missing. What scope creep actually is covers why the writing rarely turns out to be the weak link, and how to tell a client their request is out of scope covers the reply once you know.

Steps one to five are yours to run on your next kickoff call. Step six is the one worth having something else hold: start a 14-day Stria trial to lock a scope and have requests checked against it, no credit card, detection included on the free plan.

Frequently asked questions

How do you set a project scope with a client?

Six steps, in order: agree the outcome the client is buying, count the deliverables and write the exclusions, put a price on the next revision round, define when a deliverable is accepted, agree the change route before you need it, and lock the agreed list so later requests get compared to it rather than remembered against it. The order matters — every step after the first is easier once you know what the project is for.

What should a project scope include?

Counted deliverables, a named exclusions list, a revision policy with a rate attached to the round after the last included one, an acceptance window, the client's own dependencies and what happens when they slip, and a written change-order route. A scope that lists only what you will do is half a scope: the disputes come from the things nobody mentioned.

What is the difference between a project scope and a statement of work?

The scope is the agreement about what is and is not included. The statement of work is the document that records it and gets signed. You can have a clear scope conversation and still lose the argument six months later if nothing wrote it down in a form both parties accepted, which is why the last step of scoping is always to lock the record rather than to finish the call.

How do you handle a scope change mid-project?

Compare the request to the locked scope before you reply, then respond with a price rather than a yes or a no. A reply that accepts the work without mentioning money is read as confirmation the work was always included. Accepting it with an add-on estimate attached keeps the relationship and the revenue, and turns a negotiation about whether the request was reasonable into a simple approval.