Skip to content

Service Scope Statement

Published scope statement — instantiates Domain–Codomain Delimitation

A published statement of what a service does and does not deliver — the requests it handles, the outcomes it promises, what falls outside it, and where out-of-scope requests should go instead.

A Service Scope Statement bounds a service by publishing its deliverable side: the outcomes, remedies, and deliverables it commits to producing, the kinds of request it handles, and — pointedly — what it will not do, with a pointer to where those out-of-scope requests belong instead. What makes it this mechanism rather than its siblings is its outward, promissory stance: it is a public commitment to requesters that manages expectations on the output side, so people know what they can and cannot ask this service to deliver, and are redirected rather than left stranded when their need falls outside. Where Eligibility Criteria answer "who qualifies as a valid input," the Service Scope Statement answers "what will you deliver, what won't you, and where do I go if it's the latter."

Example

A city's public-works department publishes a Service Scope Statement for its road-maintenance service. In scope: filling potholes on public roads, repairing city-owned sidewalks, replacing damaged street signs — each with a stated response commitment. Explicitly out of scope: drainage on private property, tree roots on residential land, and anything on a state highway — and for each, a referral: private drainage → a licensed contractor, state highway → the state DOT, and ambiguous cases → the 311 line. A resident whose flooded driveway is on private land reads the statement, sees it is out of scope, and — crucially — sees exactly where to take the request instead of filing a ticket that would sit unhandled and then be closed as "not our department." The statement has bounded the service's codomain of deliverables and provided a soft landing for everything outside it.

How it works

The statement publishes three things: the service unit it applies to, the codomain of deliverables and outcomes it commits to (often with response levels), and an explicit out-of-scope section that pairs each exclusion with a referral or fallback. The referral is what separates a scope statement from a mere disclaimer — it turns "not us" into "not us, go here," which is what keeps requesters from bouncing. Being published and outward-facing, it does its work before a request is made, shaping what gets asked in the first place.

Tuning parameters

  • Inclusion breadth — how much the service commits to deliver. Broader scope serves more needs but stretches capacity and invites requests it can't reliably meet; narrower scope is honest but pushes more requesters elsewhere.
  • Exclusion explicitness — whether out-of-scope items are enumerated or left implicit. Naming exclusions prevents disputes but can never be exhaustive and can read as defensive.
  • Referral quality — how specific the "go here instead" pointer is. Precise referrals genuinely help requesters; vague ones ("contact someone else") are exclusions in disguise.
  • Commitment strength — how firmly outcomes are promised (best-effort vs. guaranteed with a response target). Firmer promises build trust but create obligations the service must actually meet.

When it helps, and when it misleads

Its strength is expectation management: by stating deliverables and exclusions up front, it prevents the mismatch where requesters expect outcomes the service never offered, and its referrals keep out-of-scope needs from dead-ending. Its failure modes come from the gap between the statement and reality. Gold-plating — quietly delivering beyond the stated scope to be helpful — erodes the boundary until the extra becomes an expected entitlement and the statement is fiction.[1] The opposite risk is a statement written to disclaim rather than inform — technically bounding scope while leaving requesters no real path forward. And a statement drifts out of date as the service's real capabilities change. The discipline is to keep stated scope and actual delivery in sync (letting Scope Change Review ratify genuine expansions rather than absorbing them ad hoc), and to judge every exclusion by whether its referral actually helps the requester.

How it implements the components

  • functional_unit_under_scope — names the specific service the statement bounds.
  • output_codomain — publishes the deliverables, outcomes, and remedies the service commits to producing — the output side stated as promises.
  • safe_rejection_or_deferral_path — pairs each out-of-scope item with a referral or fallback, so a request the service won't handle is redirected rather than dropped.

It is a published commitment, not an intake mechanism: deciding who qualifies as a valid input is Eligibility Criteria, operationally routing each out-of-scope case is Unsupported Case Triage Workflow, and keeping the stated scope current is Scope Change Review.

References

[1] Gold-plating — delivering more than the agreed scope, usually to be helpful. Over time it silently redraws the boundary: yesterday's favour becomes today's expectation, and the published scope no longer describes what the service actually does. ↩