Content & conversion
How to Explain Your Scope of Services on a B2B Website
Explain what your B2B service includes, excludes, and requires from clients, with a worked GEO scope example and checks for consistent proposals.
TL;DR
- State what work the buyer is paying for, what is outside it and what they must provide.
- Use the page to set clear expectations; use the proposal to agree on the details of each job.
- When the solution is unclear, sell a defined discovery phase rather than pretend the full scope is known.
Your scope of services should tell buyers what work is included, what costs extra and what they must provide. This guide shows how to express those boundaries on a public page; the project proposal still records the agreed details.
PMI’s 2014 study found that poor requirements management was the main cause of 47% of unsuccessful projects failing to meet their goals. This is a share of failed projects, not all projects. It is also not a test of website copy. But it shows why the way teams define work deserves care. PMI
A B2B service page should help buyers see what they are buying and what they need to bring. It need not settle every detail in advance. The aim is to state the normal bounds of the offer, then agree on the exact job in a proposal. If research must come first, explain what that first phase buys and which decisions it will help the client make.
What is included, excluded and required from the buyer?
Define scope in three lists: work included in the fee, work quoted separately, and inputs the client must supply. Check each list against the current quote and statement of work before publishing it.
- List the tasks needed to deliver the service, including review and release.
- Mark each task as included, optional or excluded; resolve disagreements with the service owner.
- For each client input, state what is needed, when and why. Put purchase-changing limits beside the scope, not only in small print.
What could a GEO scope of services include?
A scope of services states the work included, its boundaries and the inputs needed to deliver it. For a GEO engagement, distinguish a review from writing, implementation and ongoing monitoring.
Worked example — illustrative scope, not a Sementa package. A review could cover agreed buyer questions and named service pages, producing a findings brief and one rewritten section. Publishing changes, buying media and monthly monitoring remain outside that review unless separately agreed. The client supplies current service facts, approved evidence and a person who can resolve conflicting claims.
Before accepting the wording, match each promised activity to a named deliverable and an owner. “Improve AI visibility” describes an aim; it does not tell the buyer what work the fee buys. This distinction lets both sides resolve a scope gap before discussing price.
What if the client cannot provide an input?
Decide whether an alternative is workable. An interview may replace a missing written brief; it cannot replace permission to access a protected system. Explain the alternative and any extra work, or defer the affected part. Do not promise the same output from less evidence.
How do you handle requests added after work starts?
Compare the request with the agreed scope. If it adds work, record its effect on fee, timing and outputs and seek agreement before proceeding. The public page explains this process; the proposal records the actual terms.
Why is “full service” not enough to define scope?
“Full service” suggests breadth. Scope tells the buyer which work is part of this purchase.
One buyer may read “website optimization” as research, copy, design, development and testing. The seller may mean a review and advice. The risk lies in that gap, not in the name of the package.
Scope states the work covered and the likely extras that are not included. Inputs are what the client must supply, such as files, access or an approved decision. A page can promise a content review yet omit that it needs up-to-date service details and a person who can check the facts.
In PMI’s study of 2,066 practitioners, only 49% said their firms had the resources to manage requirements properly. Just 46% reported a formal process for unbiased validation. These are findings from 2014, not current agency benchmarks. They point to a work process that words on a page cannot fix on their own. PMI
That is why we would ask the service owner to confirm the offer before an editor rewrites it. If the team cannot agree whether publishing is included, a polished line will hide the gap. Clear copy starts with work the team can explain in the same way.
How much detail belongs on a public service page?
Include facts that help buyers decide whether to proceed. Leave the exact terms of their project for the proposal.
A public page should state the normal unit of work, key exclusions and vital client inputs. The proposal can name the pages, review rounds, access rights and dates.
There is a reason not to fix every detail too early. TrustRadius found that 83% of buyers changed their decision criteria during the buying process. That does not mean their project scope changed. It means many were still learning what mattered as they chose a supplier. TrustRadius
The page can help by separating firm boundaries from open choices. “Research and advice are included; implementation can be quoted after review” says more than “custom packages available.”
Explain inputs in the buyer’s language. “We need a named service owner to approve factual claims” is clearer than “stakeholder engagement required.” Add the reason when it is not obvious. The client can then check whether the right people and files are available before work starts.
State the kind of data needed on the page. Arrange access through a secure process once the work is agreed.
What if discovery is needed before scope can be fixed?
Define the discovery phase itself. Do not sell an exact build plan before the facts needed to create it are known.
The UK Government Service Manual treats discovery as work to understand a problem and its limits before deciding to build. It keeps discovery separate from building the service. It also allows a team to stop when further work is not justified. This is public-service guidance, not sales research, but it helps explain the difference between buying knowledge and buying a build. GOV.UK
A business can make the same distinction. State what the team will look into, what the client must share and which decision the findings will support. Do not imply that a good discovery phase must lead to a larger project.
Worked example — illustrative: agree the boundary before editing.
Compare “We improve your lead generation website” with the draft proposal and client checklist. Resolve missing tasks with the service owner, then publish the agreed boundary:
| Scope line | Buyer-facing wording |
|---|---|
| Included | Review the agreed service pages and inquiry path; deliver a ranked findings brief. |
| Client inputs | Current offers, common sales questions and approved access to relevant page data. |
| Separate work | Copywriting, development and ongoing measurement need a separate scope. |
The completion check is agreement across the page, proposal and checklist. If publishing appears in only one, settle that difference first. Better wording cannot resolve an offer the team has not agreed.
How does scope fit the eight-dimension framework?
Scope and inputs set the bounds of the work. Deliverables name the outputs the client receives.
Sementa’s 8-Dimension B2B Service Page Audit Framework compares the page with the quote, statement of work and client checklist. The aim is to make them agree, not to publish more fine print.
Buyers should be able to see what they are considering, what they must supply and what still needs a discussion. When the website and delivery team give different answers, resolve the offer first.
Scope and Inputs: Common Questions
Is scope the same as a deliverable?
No. Scope defines the work included and excluded; a deliverable is an output the buyer receives. A review may include interviews and page analysis but deliver a findings brief. State both so buyers do not mistake activities for items handed over.
Should the public page list every exclusion?
List exclusions likely to change the purchase or be mistaken for included work. Keep detailed project-specific boundaries in the proposal, without contradicting the page. A long list of unlikely exclusions can obscure the few that buyers actually need.
Can scope be agreed before access is granted?
You can agree a provisional scope with explicit assumptions and a checkpoint for confirming it. Identify which tasks depend on access and what will happen if the assumptions fail. Do not present an unverified scope as final.
Who resolves a mismatch between the page and proposal?
The service owner should confirm the current offer with sales and delivery, then have the affected materials corrected. An editor should not choose whichever version is easier to write. If a buyer already relied on conflicting wording, clarify the difference directly before work proceeds.
For a broader review, use our B2B service page checklist.
Share the service page, proposal and client-input list to scope a service-boundary review.
