A clear service scope without ambiguity: 10 elements that show the client what they are buying

Current U.S. Federal Acquisition Regulation guidance for performance-based services recommends describing work primarily in terms of required results rather than prescribing how it must be performed or simply specifying a number of hours. It also refers to measurable performance standards and, in statements of objectives, identifies elements such as purpose, scope, period and place of performance, background, required results and operating constraints. [1]

The UK Digital, Data and Technology Playbook likewise promotes clear, outcome-based specifications. It explicitly recommends focusing on the user and the problem to be solved rather than prescribing a technical solution in advance. [2]

The current UK guidance on risk allocation and pricing further states that performance measures should be measurable and objective, and that suppliers should be held accountable for results they can actually influence. [3]

These are public-procurement sources, not a universal template for every service. They do, however, illustrate a highly useful principle: a good scope should name the expected result, how it can be assessed and the limits of responsibility.

A good service description should help:

The client - understand what they will receive, what they will not receive and what will be required from them.

The specialist - define responsibility boundaries, assumptions and the point at which a new request becomes a scope change.

Both sides - agree on how they can reasonably determine that the agreed work has been completed.

If the description serves only one of these functions well, it can still leave significant room for disputes or different interpretations.

Start by explaining why the service is needed.

Do not begin with a list of tools or activities if the client does not yet understand the purpose.

Instead of:

"Analytics, reporting and event configuration."

prefer something like:

"The purpose is to obtain reliable data showing at which stages users most often abandon the form, so the team can identify areas that need improvement."

This reflects the principle of describing needs and outcomes rather than prescribing a solution, as promoted by the UK Digital, Data and Technology Playbook. [2]

The objective answers "why?", while the outcome answers "what should exist or be true when the work is finished?"

An outcome might be:

• a completed document,
• a working feature,
• an implemented configuration,
• completed research with conclusions,
• a prepared set of materials,
• a delivered session with a defined summary.

For performance-based services, the FAR describes requirements primarily through required results rather than only the method of performance. [1]

That does not mean every service should guarantee a business result the specialist cannot control. A specialist may commit to launching a campaign within an agreed scope, but a guaranteed 30% sales increase may depend on many factors outside the provider's control.

The scope should name the concrete parts of the work covered by the agreement.

For a website project, for example, this might include:

• review of the current website,
• information architecture,
• design of a defined number of views,
• mobile versions,
• implementation of the approved design,
• basic handover documentation.

The point is not to create the longest possible list. The point is to name the major elements that affect effort and expectations before work begins.

The scope describes the work, while deliverables describe what the client will actually receive.

Examples include:

• a source file,
• a report in a defined format,
• a working module,
• a code repository,
• a set of graphics,
• a recording,
• documentation,
• a list of recommendations,
• access to a configured environment.

If the form of the result matters, name it. "Report" could mean two pages of text or a detailed document with analysis, priorities and examples. The label alone is not always enough.

Acceptance criteria answer the question: how can the parties determine that the agreed result has been delivered in line with the requirement?

They can concern, for example:

• completeness,
• compliance with the agreed specification,
• a required format,
• operation on specified devices or environments,
• a maximum number of errors of a defined category,
• delivery time,
• defined quality parameters.

The FAR requires performance standards in performance-based service contracts to be measurable and structured so performance can be assessed. [1]

The UK risk-allocation guidance further says measures should be objective and relate to results the supplier can influence. [3]

That is why "the client will be satisfied" is much less useful than a criterion tied to a specific, observable result.

A service often depends on actions by the other party.

It is useful to state whether the client must provide:

• system access,
• content or materials,
• data,
• brand information,
• decisions and approvals,
• a contact person,
• a test environment,
• responses within a defined time.

If missing client inputs can stop the work, that should be clear.

Responsibility for timing should not be written as though the specialist controls actions they do not actually control.

Price and timing are often valid only under specific assumptions.

Examples:

• the existing database is available and works correctly,
• the client has rights to the materials they provide,
• an external system has a working interface,
• the project does not require historical data migration,
• the number of language versions is fixed in advance,
• decisions will be made by one designated person.

GAO's guide to reliable cost estimating treats clear scope, technical baselines, ground rules and assumptions, and risk and uncertainty analysis as important elements of a sound estimating process. [7]

A small service does not need to copy a process designed for major programs. The principle is still valuable: if the estimate depends on something that may turn out not to be true, say so.

Exclusions are not a sign of a weak offer. They are often a sign of a well-defined commitment.

If something could easily be mistaken for part of the service, it can be helpful to state explicitly that it is not included.

Examples:

• licence purchases,
• content creation,
• paid imagery,
• translation,
• post-launch maintenance,
• work on another system,
• unlimited revisions,
• third-party service costs.

There is no need to list everything the specialist will not do. The most useful exclusions are those the client could realistically assume were part of the service.

A timeline should say more than "around two weeks" when progress depends on client approvals or materials.

It can clarify:

• what starts the clock,
• whether there are intermediate stages,
• which decisions close each stage,
• how long the client has to respond when that affects the schedule,
• how delays are communicated,
• how final acceptance works.

For a simple service, a few sentences can be enough. In a larger engagement, stages help both sides understand what has already been completed and what needs to happen next.

A good service description should explain what happens when a new requirement appears after work starts.

A practical mechanism can be very simple:

"Work outside the described scope requires confirmation of the new scope, its impact on timing and any additional price before that work begins."

It is also useful to state clearly:

• the pricing model,
• the price or how it is calculated,
• payment rules,
• additional costs that may arise,
• rules for extra revision rounds.

This does not eliminate change. It makes a change a conscious decision rather than a hidden expansion of the original commitment.

A clear scope does not require controlling every step of the specialist's process.

The UK Digital, Data and Technology Playbook warns against over-specifying the solution and notes that outcome-based specifications can leave suppliers room to propose a more effective way to solve the problem. [2]

The FAR similarly prefers descriptions of required results over prescribing exactly how the work must be performed. [1]

Therefore:

"the website must correctly support the agreed scenarios on the specified devices"

may be a better requirement than prescribing the exact implementation when the technology itself is not an essential constraint.

Of course, the method can matter in some services because of security, compliance, integration or a required technical standard. In those cases it should be stated.

When defining scope, it is important to distinguish between:

the specialist's work product and a business outcome that also depends on other factors.

A specialist can commit to:

• preparing and launching a campaign within an agreed scope,
• performing an analysis,
• delivering a defined number of materials,
• implementing a feature that meets defined criteria.

Guarantees around sales, customer numbers, search ranking or other outcomes that depend on the market, budget, product, client actions or external systems require much greater caution.

Current UK risk-allocation guidance explicitly says suppliers should be accountable for results they can influence. [3]

A good description does not weaken accountability. It places accountability where control actually exists.

Not every service needs a multi-page document.

For a simple task, the essential information may fit into a few paragraphs. For a larger project, the same thinking can expand into a detailed specification, schedule, acceptance criteria and formal change process.

A sample Terms of Reference published by the World Bank notes that such a document should clearly articulate the requirements for the consulting services and the contracting authority's expectations, and that it must be adapted to the specific project and local circumstances. [4]

Length is not the key issue. The key question is whether missing information could realistically change the price, timeline, responsibility or expected result.

A service description on a website or profile may be only one part of the contracting process. Specific legal duties depend on the country, transaction type, status of the parties and method of sale.

For business-to-consumer transactions in the EU, the official Your Europe portal identifies pre-contract information including the main characteristics of the service, the total price including charges, payment and performance arrangements and, where relevant, the contract duration. [5]

EU guidance for businesses also states that standard consumer contract terms must be fair and written in plain, understandable language so that the consumer can understand their economic consequences. [6]

These requirements concern defined consumer relationships in the EU. They should not automatically be extended to every business-to-business transaction or to other jurisdictions.

This article is editorial guidance on describing services, not a contract template or legal advice.

1. Does the client understand the problem or objective the service addresses?
2. Is the final outcome named?
3. Is it clear what is included in scope?
4. Does the client know which concrete deliverables they will receive?
5. Is there a reasonable way to assess completion?
6. Is it clear what the client must provide or take care of?
7. Are the most important assumptions visible?
8. Are obvious, potentially confusing exclusions stated?
9. Do the timeline and stages reflect dependencies on both sides?
10. Is it clear what happens when scope changes?
11. Are price, pricing model and additional costs presented at the appropriate stage?
12. Does the description avoid promising an outcome the specialist cannot control?

The best test of a good description is simple.

After reading it, the client and the specialist should give similar answers to these questions:

What should be achieved? What will be done? What will the client receive? What is not included? What must the client do? How will we know the work is complete? What happens if the scope changes?

If the answers align, the price and timeline have much better context.

If the answers differ, the problem often does not begin during delivery. It begins in the service description.

[1] U.S. Federal Acquisition Regulation - Subpart 37.6, Performance-Based Acquisition
Open source

[2] UK Government - The Digital, Data and Technology Playbook
Open source

[3] UK Government - Risk Allocation and Pricing Approaches Guidance Note
Open source

[4] World Bank - Sample Consultants Terms of Reference
Open source

[5] Your Europe - Contract information: what you should know before buying
Open source

[6] Your Europe - Contracts with consumers
Open source

[7] U.S. Government Accountability Office - Cost Estimating and Assessment Guide, GAO-20-195G
Open source

Methodology note: the sources have different scopes and do not form one common standard for service descriptions. This article uses only the principles they actually support: focus on outcomes, measurability, clear scope, assumptions, accountability for factors within the provider's control, and transparent information for the client.