Services Inventory and Attributes

Description — The single named individual or role accountable for the Service’s definition, value, boundaries, performance expectations, lifecycle state, and continuous improvement. Aligns with the first element of the IF4IT Single Service Definition Pattern.

Benefit(s) — Creates clear accountability for the Service as a managed asset. Prevents the Service from becoming an ownerless catalog entry, request form, or workflow. Enables governance escalation and decision-making about the Service.

Source — Manual.

Examples — Jane Smith, VP of Employee Experience; Bob Jones, Director of Customer API Platform; Maria Garcia, Head of IT Service Operations

Notes — Refer to the IF4IT Service Management Best Practices document for the Service Owner accountability model. Service Owner is distinct from Service Manager (operational coordination), Service Provider / Service Actor (work performance), and Service Requester Community (consumption).

Description — The role responsible for day-to-day operational coordination of the Service — managing queues, providers, schedules, escalations, handoffs, operating procedures, knowledge articles, fulfillment quality, and service reporting. Aligns with the sixth element of the IF4IT Single Service Definition Pattern.

Benefit(s) — Provides operational coordination distinct from accountable ownership. Enables the Service Owner to remain accountable for strategic Service direction while the Service Manager handles day-to-day operations. Improves operational consistency without weakening Service Owner accountability.

Source — Manual.

Examples — Carlos Martinez, Onboarding Operations Manager; Priya Patel, API Platform Operations Manager

Notes — In smaller organizations, the Service Owner and Service Manager may be the same person. In larger organizations, they are typically separate roles. Record the actual role assignment, not the formal title.

Service Providers / Service Actors

[Multi-Value]

Description — The people, teams, systems, applications, automations, or technologies that perform the work needed to fulfill Service Requests and produce Service Outcomes. Aligns with the seventh element of the IF4IT Single Service Definition Pattern. Distinct from the Service Owner (who is accountable) and the Service Manager (who coordinates).

Benefit(s) — Makes Service fulfillment responsibility legible. Enables impact analysis: when a Service Provider team changes, leaves, or is restructured, which Services are affected? Aligns Service Records routing to the correct fulfillment teams.

Source — Manual.

Examples — "Service Desk Tier 1 team; HR Operations; IAM Provisioning Automation" or "Customer API Platform team; AWS API Gateway"

Notes — For human-delivered Services, record the teams or roles performing the work. For technology-delivered Services, record the systems, applications, or automations performing the work. For Hybrid Services, record both.

Description — The internal organization or external Vendor that provides the Service. For internal-provided Services, this is typically a function or department; for externally-consumed Services, this is the Vendor.

Benefit(s) — Connects Service governance to organizational and Vendor governance. Enables joint analysis of Service portfolio by provider organization. For Vendor-provided Services, links to the Vendors Inventory for concentration analysis.

Source — Manual.

Examples — IT Operations; HR Service Center; Salesforce Inc.; Amazon Web Services

Notes — For Services with multiple provider organizations, record the dominant provider; record additional providers in Subcontracted Vendors (in the Vendor and Supplier Attributes category) or as additional Service Providers.

Service Requester Community

[Multi-Value]

Description — The actual population of Service Requesters who consume the Service. Where Customer Segment captures who the Service is designed for, Service Requester Community captures who actually requests it.

Benefit(s) — Enables consumption-pattern analysis. Reveals Services that are over-consumed by one audience and under-consumed by their target audience. Supports Service evolution decisions informed by actual consumer behavior.

Source — Manual.

Examples — "All employees; contractors; new hires" or "Customer applications integrated via the public API; partner systems"

Notes — May be expressed as broad communities (e.g., "All Employees") or as specific organizational units. Should be kept current as Service consumption patterns evolve.

SME / Specialist Escalation Teams

[Multi-Value]

Description — The Subject Matter Expert teams that handle complex Service Requests escalated from the Service Desk or Service Provider Workforce. Per the IF4IT Single Service Definition Pattern, SME Teams are a distinct layer behind the front-line Service Provider Workforce.

Benefit(s) — Makes escalation paths explicit. Enables governance of SME team capacity: which Services depend on which SME teams, where SME bottlenecks may emerge, and where SME capacity warrants investment.

Source — Manual.

Examples — "Active Directory SMEs; Network Engineering escalation team" or "Database performance SMEs; Security engineering escalation team"

Notes — Distinct from Service Providers / Service Actors who handle routine fulfillment. SME Teams are the second-line specialists. Not every Service has SME Teams — some Services are fully handled by the Service Provider Workforce.

Description — The business-side individual or role accountable for the Service’s business value and business-side governance, when distinct from the Service Owner. Common in enterprises where business and technical accountability are governed separately.

Benefit(s) — Provides explicit business-side accountability for Services that are technically implemented but business-owned. Supports governance escalation through the business chain when Service business value or business-side commitments are at stake.

Source — Manual.

Examples — Sandra Lee, VP of Customer Experience; Tom Wilson, Director of Revenue Operations

Notes — May be empty for Services where the Service Owner IS the business owner. Record only when the role is distinct.

Description — The technical-side individual or role accountable for the Service’s technical implementation and technical governance, when distinct from the Service Owner. Common in enterprises where business and technical accountability are governed separately.

Benefit(s) — Provides explicit technical-side accountability for Services that have substantive technical implementation considerations. Supports technical governance escalation when Service architecture, technology selection, or technical performance is at stake.

Source — Manual.

Examples — Raj Singh, Principal Engineer; Lisa Chen, Engineering Manager for Customer API Platform

Notes — May be empty for Services where the Service Owner IS the technical owner. Record only when the role is distinct.

Description — The role accountable for the accuracy, currency, and structure of this Service’s entry in the Service Catalog. Refer to the IF4IT Service Catalog Best Practices document for the Catalog Manager discipline.

Benefit(s) — Provides explicit accountability for the requester-facing presentation of the Service. Prevents stale catalog entries, broken request paths, and inconsistent Service descriptions across catalog locations.

Source — Manual.

Examples — Anna Williams, Service Catalog Editor; Service Catalog team

Notes — May be the same person as the Service Engagement Owner, or may be a different role specifically responsible for catalog entry quality.

Description — The role accountable for the accuracy and consistency of the Service’s representation across all Service Engagement Channels — Service Catalog, departmental portals, intranet pages, API catalog entries, chatbot answers, and other engagement surfaces.

Benefit(s) — Provides explicit accountability for cross-channel consistency. Reduces conflicting Service descriptions across engagement surfaces. Aligns with the IF4IT Service Management Best Practices "Assign ownership for Service Catalog, Service Facade, and Service Engagement content" guidance.

Source — Manual.

Examples — Marcus Brown, Service Engagement Lead; Helpdesk Content team

Notes — Where the Service is exposed through a single channel only, this role may be redundant with the Catalog Manager. Record only when the role is distinct.

Description — The role accountable for the overall health, strategic direction, investment, value, lifecycle balance, and performance of the Service Portfolio to which this Service belongs. Portfolio Owners govern at the portfolio level; individual Service Owners govern at the Service level.

Benefit(s) — Enables strategic Service portfolio decisions. Supports portfolio-level investment planning, Service rationalization, and lifecycle balance management. Provides leadership-level reporting on Service portfolio health.

Source — Manual.

Examples — David Kim, VP of End User Experience (End User Services Portfolio Owner); Patricia Adams, Director of API Platform (API Services Portfolio Owner)

Notes — Portfolio ownership does not replace Service ownership; it provides a higher-level governance view across related Services. Refer to the IF4IT Service Management Best Practices document for the Portfolio Owner discipline.

Description — The role accountable for the coherent governance of the Service Group to which this Service belongs. Service Groups organize related Services by fulfillment responsibility, service area, requester community, operational capability, or business context — sitting between individual Services and Service Portfolios in scale.

Benefit(s) — Enables coordinated governance of related Services. Supports consistency of Service Definitions within a group, alignment of Service Expectations, and shared engagement standards.

Source — Manual.

Examples — Kevin Park, Manager of Access Management Services (Access Services Group Owner)

Notes — Not every Service belongs to a Service Group. Record only when a Service Group structure exists.

Description — The named individual or role at the Vendor who is the enterprise’s primary contact for this Service. For consumed Services only.

Benefit(s) — Enables efficient escalation and account management. Supports Vendor relationship continuity through staff changes by recording the contact role rather than only an individual name.

Source — Manual.

Examples — David Park, Senior Customer Success Manager at Salesforce; AWS Technical Account Manager

Notes — Refer to the Vendors Inventory for broader Vendor relationship management — Vendor Contact at the Service level is for Service-specific account management.

Escalation Contacts

[Multi-Value]

Description — The named individuals or roles to be contacted for escalation when standard Service Provider response is insufficient. Multi-value to capture the escalation chain.

Benefit(s) — Reduces escalation friction during Service incidents. Provides a clear path from Service Desk to senior accountability. Supports Service Records routing rules.

Source — Manual.

Examples — "L1: Service Manager (Carlos Martinez); L2: Service Owner (Jane Smith); L3: Portfolio Owner (David Kim)"

Notes — Record the escalation tier with each contact. Should be reviewed when ownership changes occur.