In-scope vs out-of-scope

Why the out-of-scope list is the important one

If it isn't excluded, a reasonable client can assume it's included. That single sentence explains most project disputes. The in-scope list tells the client what they're getting; the out-of-scope list tells them where the edge is, and the edge is where money is made or lost.

Naming exclusions isn't defensive or mean. It's a sign you've done this before. A client reading a clear out-of-scope section thinks "these people know where projects go wrong", not "these people are trying to get out of things". It also makes every later addition a visible, priced decision rather than a silent expectation, the core of preventing scope creep.

Write them as parallel, specific pairs

The trick is to write both lists at the same level of detail, as matched pairs. Vague scope is where overrun lives.

• Weak: "Includes SEO."

Strong: "In scope: page titles, meta descriptions and an XML sitemap for the 12 built pages. Out of scope: ongoing SEO, keyword research, link building and content writing."

• Weak: "Responsive design."

Strong: "In scope: layouts tested on current Chrome, Safari, Firefox, Edge, iOS and Android. Out of scope: Internet Explorer and legacy browser support."

• Weak: "Content added."

Strong: "In scope: population of up to 12 pages from client-supplied copy and images. Out of scope: copywriting, image sourcing, licensing and retouching."

The pattern is always the same: state the boundary in numbers and named things, not adjectives.

A phrase bank of common exclusions

These are the exclusions most web projects need and most quotes forget. Adapt the numbers to the job.

• Content, "copywriting, translation, image sourcing and licensing are not included; client

supplies final copy and assets."

• Data, "migration of existing content or products is out of scope unless separately quoted."
• Integrations, "integrations beyond the [named] services are out of scope."
• SEO and marketing, "ongoing SEO, PPC, analytics setup and email marketing are not included."
• Browser and device support, "support limited to current major browsers; legacy versions

excluded."

• Revisions, "up to [n] rounds of changes per stage; further rounds billed at standard rate."

See revision limits.

• Hosting and maintenance, "hosting, domains, SSL and post-launch maintenance are out of scope

unless a support plan is agreed."

• Third-party costs, "licences, plugins, fonts and stock are billed at cost or supplied by the

client."

Handle the grey areas on purpose

Some things sit genuinely between in and out, and those are the ones to address directly rather than hope nobody asks. A good move is to list them as assumptions ("assumes one brand identity applies", "assumes hosting already exists") or offer them as optional extras the client can choose to add. Either way, you've named the grey area instead of leaving it to a future argument.

Keep the boundary visible during the build

An in/out list only works if the delivery team can see it. When the agreed scope is buried in a signed PDF, there's nothing to check a "quick favour" against. Keeping the scope live, the same document from quote through to the build plan, means the boundary you agreed is right there against the work. That continuity is the point of ScopeDeck's quote-to-spec-to-tasks workflow.