Delivery model

Move work without losing ownership.

The operating model separates relationship decisions from repeatable delivery, then names what happens when work is unclear, risky, or outside scope.

Request handling

The operating standard for accepted work.

The request uses the identity and channel agreed with your practice.

Your practice retains: the client promise and front-door decision.

Delivery checks the request against the client group, service area, and written boundary.

Delivery handles: accepted work inside that boundary.

Material risk, unclear authority, and out-of-scope work stop with context and a clear decision request.

Your practice decides: relationship-sensitive or commercial questions.

Recurring friction and repeated exceptions become explicit scope and operating discussions.

Both teams review: whether the written agreement still matches the work.

Responsibility table

Your practice	Client contract, retail offer, advisory voice, relationship risk, and change approval.
Delivery	Accepted work inside the agreed clients, users, tenants, tools, channels, and coverage boundary.
Written agreement	Inclusions, exclusions, coverage, escalation owners, decision rights, and review path.
Never implied	Unlimited projects, on-site service, after-hours coverage, procurement, specialist security work, or guaranteed service levels.

Handoff standard

RequestRequester, affected users, impact, and client context.
Work stateActions already taken, known environment, and approved next step.
Decision rightsWhat delivery may do, what requires approval, and who can decide.
Exception pathNamed owner, safe stopping point, and information needed for a decision.

This standard is a scoping aid, not evidence of a specific integration, toolset, or service level.

The service catalog turns ownership into concrete support and stewardship boundaries.