CMS Hybrid Cloud

Support work was distributed across product teams, shared services, platform operations, and vendor relationships, each with its own way of describing what it did and how it handled customer needs. There was no shared model connecting those parts.

A Customer Support Services Operating Model introduced the initial structure: core roles including Hosting Coordinator, Technical Advisor, and Financial Analyst; customer engagement responsibilities; supporting operational functions; and cross-team coordination needs. It created the first shared view of how Hybrid Cloud Customer Support Services was taking shape. From there, blueprint expansion work began connecting those roles to lifecycle activities, governance interactions, supporting tools, service capabilities, and operational dependencies — moving from a role model into a picture of the full support ecosystem.

The output gave the team a common reference point — naming the services, surfacing the relationships between them, and making visible the operational seams where handoffs, gaps, and coordination needs lived.

The operating model revealed something the team had not fully named: ownership was assumed rather than assigned. Individual teams understood their responsibilities, but there was no shared model for how those responsibilities fit together or how decisions, information, and workflows moved across them.

The work identified ten operational roles — Hosting Coordinator, Technical Advisor, Financial Analyst, FinOps Engineer, Data Auditor, Super Admin, Technical Writer, Oversight and Management, General Consumer, and QA Tester — and connected each to their operational needs, workflow participation, permissions, and decision support responsibilities. Role profiles and a CRM ownership model then gave teams a clearer picture of how support work actually moved through the ecosystem: who owned which decisions, what information each role needed, and where dashboard and workflow gaps concentrated.

The result was a shared ownership model that gave leadership a tool for making responsibility decisions proactively — rather than discovering ownership ambiguity during incidents or escalations.

Even with ownership defined, the team lacked a shared model for how services moved through their lifecycle. Onboarding (ONBI) and Ongoing Operations and Management (O&M) had each developed their own frameworks, but no single model connected them into a picture of end-to-end delivery.

An integrated lifecycle blueprint brought ONBI and O&M together into one model, spanning six stages: Customer Interest, Onboarding, Operational Management, Optimization, Governance, and Decommissioning. Each stage was mapped against the customer engagement activities, technical enablement needs, cost optimization requirements, governance touchpoints, and operational rhythms involved.

The blueprint gave the team a shared language for talking about delivery and a planning tool for identifying where operational gaps would emerge as workload scaled. It also made visible where each lifecycle phase created different demands on support staffing, tooling, and governance.

Each team in the Hybrid Cloud ecosystem had a coherent view of their own service area. What no one had was a view of how those service areas connected from the customer's perspective — or how much of what customers experienced depended on services outside Customer Support's direct control.

A shared services dependency map surfaced the full range of operational relationships involved: Product Engineering, Operations, Security, Cost Management, Platform Administration, Governance Functions, Observability, and Funding. These were no longer invisible dependencies — they became visible participants in the customer experience, each shaping what customers encountered at different lifecycle stages.

The map gave teams a foundation for shared planning, governance conversations, and cross-team coordination — focusing improvement not just on individual services, but on the relationships between them.

Operational data existed, but it was scattered across ONBI findings, O&M patterns, customer readiness gaps, governance friction, and shared service dependencies. There was no shared structure for organizing those signals into an improvement practice.

An Operational Findings Repository organized recurring friction, readiness gaps, governance issues, and improvement opportunities into a structure teams could use for prioritization. ONBI findings analysis, O&M analysis frameworks, and customer readiness frameworks gave teams a consistent way to examine what the data revealed. Cloud optimization workshops and action planning turned findings into decisions.

Making analysis a recurring practice — rather than a reactive one — gave the team a growing body of evidence about where services were maturing, where they were struggling, and where interventions would have the most impact.

A pattern had emerged: without active stewardship, the maps became stale, ownership models drifted, the analysis cadence lapsed, and operational knowledge dispersed. The ecosystem was not lacking visibility. It was lacking mechanisms for continuous evolution.

The work developed a Service Stewardship Framework connecting seven elements into one operating system: a Service Playbook, a Service Evolution Maturity Model, a Stage-Based Readiness Framework, a Process and Task Guidance Architecture, a CRM Guidance Vision, a Historical Service Repository, and a stewardship governance model. Each addressed a different dimension of the same challenge — how to keep service knowledge current, improvement continuous, and operational memory accessible.

The result was not a set of documents. It was a living practice — embedded in how the team worked, reviewed, improved, and evolved its services over time.