Services Inventory and Attributes

Description — The primary classification of what kind of Service this is. Drives governance pattern selection: different Service Types warrant different governance intensity, different Service Expectation patterns, and different ownership models.

Benefit(s) — Enables Service portfolio analysis by type. Reveals the enterprise’s Service mix and informs governance model design. Supports Service Catalog organization and Service Engagement Channel selection.

Source — Manual.

Examples — Business Service, Technology Service, Shared Service, Customer-Facing Service, Internal Support Service, Cloud Service, Managed Service

Notes — A Service may fit multiple Service Types. Record the dominant Service Type. Refer to the IF4IT Service Management Best Practices document for the definitional treatment of each Service Type.

Description — How the Service is delivered to its Service Requester Community. The IF4IT Service Management Best Practices document is explicit that Service Management must accommodate both human-delivered and technology-delivered Services with consistent governance discipline.

Benefit(s) — Drives operational design choices: human-delivered Services warrant queue management, staffing analysis, and Service Desk integration; technology-delivered Services warrant API governance, automated monitoring, and platform reliability engineering. Misclassifying delivery mode leads to misaligned operational investment.

Source — Manual.

Examples — Human-Delivered, Technology-Delivered, Hybrid

Notes — Valid values: Human-Delivered (work performed primarily by people), Technology-Delivered (work performed primarily by automated systems), Hybrid (a meaningful combination of human and technology delivery). Many Services are Hybrid — a human-delivered Service that uses workflow automation, or a technology-delivered Service with human escalation paths.

Description — How the Service Requester Community engages the Service. Drives Service Engagement Channel selection and informs the consumer experience design.

Benefit(s) — Enables the enterprise to design appropriate engagement channels for each Service. A Requestable Service warrants a request form and approval workflow; an Invokable Service warrants API documentation and authentication; a Consumable Service warrants discovery surfaces; a Subscribed Service warrants subscription lifecycle management.

Source — Manual.

Examples — Requestable, Invokable, Consumable, Subscribed

Notes — Valid values: Requestable (Service Requester submits a Service Request through an engagement channel), Invokable (Service is triggered programmatically, typically via API), Consumable (Service is continuously available for direct use), Subscribed (Service Requester has standing access through a subscription).

Description — Whether the Service is offered by the enterprise, consumed by the enterprise, or both. Distinguishes Services the enterprise provides from Services the enterprise depends on.

Benefit(s) — Enables joint analysis of the enterprise’s Service portfolio across direction: which Services we provide vs. which we consume, where vendor dependency concentrates, where internal Service Provider capacity is constrained.

Source — Manual.

Examples — Internal-Provided, External-Provided, Internal-Consumed, External-Consumed, Both

Notes — A Service may legitimately be both — provided to internal Service Requesters while also being consumed from an external Vendor (a reseller pattern). Record the dominant direction; use Both when neither direction dominates.

Customer Segment

[Multi-Value]

Description — The customer or consumer segment(s) the Service is designed to serve. The IF4IT Service Management Best Practices document treats Customer Segment as a defining attribute of a Service-as-Product framing — every Service should know who its consumers are.

Benefit(s) — Enables Service portfolio analysis by consumer audience. Reveals which consumer segments are well-served and which are under-served by the current Service portfolio. Supports Service investment and prioritization decisions.

Source — Manual.

Examples — All Employees, New Hires, Engineering Staff, External Customers, Partner Organizations

Notes — Distinct from the Service Requester Community attribute in the Ownership and Stakeholder category: Customer Segment is a classification of who the Service is for as a designed audience; Service Requester Community is the operational record of who actually requests the Service.

Service Category

[Hierarchical]

Description — The functional category of the Service within the enterprise Service taxonomy. Typically expressed as a hierarchical path: Domain > Sub-Domain > Category.

Benefit(s) — Enables Service Catalog organization. Supports Service Group formation and Service Portfolio structure. Allows portfolio-level analysis by functional area.

Source — Manual.

Examples — End User Services > Productivity > Email; Infrastructure Services > Compute > Virtual Machines; HR Services > Employment Lifecycle > Onboarding

Notes — Use the enterprise’s existing Service Catalog category taxonomy where one exists. If the enterprise does not yet have a Service category taxonomy, this attribute is one of the first places the taxonomy will emerge during inventory population.

Description — The strategic importance classification of this Service to the enterprise. Drives governance investment proportional to Service importance.

Benefit(s) — Enables Service portfolio analysis by criticality. Tier 1 Services warrant intensive governance — quarterly reviews, board-level visibility, formal Service Agreements, robust DR planning. Tier 4 Services can be managed through lightweight governance.

Source — Manual.

Examples — Tier 1 (Critical — enterprise cannot operate without this Service), Tier 2 (Important — significant impact if degraded), Tier 3 (Standard — manageable impact), Tier 4 (Commodity — easily replaceable)

Notes — Valid values: Tier 1, Tier 2, Tier 3, Tier 4. Service Tier is a strategic designation reviewed annually or on significant Service change. Distinct from Strategic Importance (a similar but more granular strategic-context classification).

Description — Where and how this Service is visible in the Service Catalog and other Service Engagement Channels. Governs the requester-facing presentation of the Service.

Benefit(s) — Allows the enterprise to govern which Services appear to which Service Requester Communities. Supports Service Pipeline discipline (Services in Pipeline state should not be visible in the active catalog), Service deprecation (deprecated Services may be visible but flagged), and Service retirement (retired Services should be hidden from active discovery).

Source — Manual.

Examples — Published in Service Catalog, Internal Only, Restricted to Specific Audience, Pipeline (Not Yet Cataloged), Retired-Hidden, Not in Catalog

Notes — The Service Catalog itself is governed in the IF4IT Service Catalog Best Practices document. This attribute records the Service’s catalog visibility state but does not duplicate catalog entry content.