Services Inventory and Attributes - Glossary of Terms and Phrases
Services Inventory and Attributes
Chapter 2. Glossary of Terms and Phrases
The following terms are used throughout this document with specific meanings. Terms defined in the IF4IT Enterprise Inventory Management Best Practices document or in discipline-specific Best Practices documents (APM, TPM, etc.) are not duplicated here — refer to those documents for broader inventory governance and discipline-specific vocabulary.
| Term | Definition |
|---|---|
| Service | A defined, governed offering — business or technology — that the enterprise provides to or receives from a defined set of consumers, with associated obligations, ownership, lifecycle, and operational behavior. A governed Service has clearly identified ownership, defined purpose and description, defined performance expectations, defined inputs and outputs, defined Service Manager, defined Service Providers / Service Actors, and defined supporting tools and technologies. Distinct from an Application (which may enable many Services), a Capability (which is the standing ability a Service realizes), and a Service Request (which is a single transactional instance of a Service being invoked). |
| Service Definition | The formal specification of what a Service is, who it serves, what it consumes, what it produces, and how it performs. Per the IF4IT Single Service Definition Pattern, a complete Service Definition includes eight elements: a clearly identified and accountable Service Owner, a clearly defined purpose and description, clearly defined performance expectations (Service Indicators, Service Objectives, and Service Agreements), clearly defined inputs, clearly defined outputs, a clearly defined Service Manager, clearly defined Service Providers / Service Actors, and clearly defined supporting tools and technologies. |
| Service Owner | The single named individual or role accountable for a Service’s definition, value, boundaries, performance expectations, lifecycle state, and continuous improvement. Distinct from the Service Manager (who coordinates day-to-day operations), the Service Provider / Service Actor (who performs the work), and the Service Customer / Service Requester (who consumes the Service). |
| Service Manager | The role responsible for day-to-day operational coordination of a Service — managing queues, providers, schedules, escalations, handoffs, operating procedures, knowledge articles, fulfillment quality, and service reporting. In smaller organizations, the Service Owner and Service Manager may be the same person; in larger organizations they are typically separate roles. |
| Service Provider (a.k.a. Service Actor) | The person, team, system, application, automation, or technology that performs the work needed to fulfill a Service Request and produce a Service Outcome. Service Providers may be internal (Service Desk staff, application support teams, automated workflows) or external (vendor support teams, SaaS platforms). |
| Service Requester (a.k.a. Service Customer) | The person, organization, or system that requests, invokes, or consumes a Service. Service Requesters may be internal (employees, internal teams, internal applications) or external (customers, partners, external systems). The collective set of Service Requesters for a given Service is the Service’s Service Requester Community. |
| Service Request | A specification, instruction, trigger, input, or set of criteria submitted by a Service Requester to initiate a Service. Also informally known as a Service Ticket. A Service Request is a single transactional instance of a Service being invoked — not the Service definition itself. |
| Service Action | The work performed by one or more Service Providers in response to a Service Request. The Service Action is bounded by the Service Definition and produces a Service Outcome. |
| Service Outcome | The result produced by a Service Provider according to the Service’s predefined Service Expectations. A Service Outcome may include a Service Response, a deliverable, a completed transaction, a changed state, a notification, a record update, or another measurable result. |
| Service Response | A specific form of Service Outcome — typically an immediate or near-immediate response delivered back to the Service Requester. Common for technology-delivered Services (API request/response patterns) and some human-delivered Services (Service Desk acknowledgement). |
| Service Expectations | A set of predefined requirements set by the Service Owner for how a Service will be structured, enabled, and performed in a manner that guarantees measurable, predictable, and acceptable results. Composed of three traits: Service Indicators, Service Objectives, and Service Agreements. |
| Service Indicator | An observable or measurable signal used to understand Service demand, performance, quality, behavior, risk, experience, or outcome. Service Indicators provide the measurement foundation for Service Objectives, Service Agreements, Service Reports, and continuous improvement. |
| Service Objective | A target, threshold, or desired range for one or more Service Indicators over a defined period or operating context. Service Objectives translate measurement into performance intent. |
| Service Agreement | A documented commitment, understanding, or agreement that defines responsibilities, expectations, targets, assumptions, escalation paths, and responses when expectations are met or missed. A Service Agreement may be a formal Service Level Agreement (SLA), an internal operating commitment, a support agreement, a customer-facing service commitment, or a documented understanding between the Service Owner and the Service Requester Community. Not every Service Agreement has formal legal or financial consequences. |
| Service Catalog | The requester-facing view of approved, active, requestable, invokable, or consumable Services. A curated subset of the broader Service Portfolio. The Service Catalog is a peer of the Services Inventory within Service Governance: the inventory governs the full set of Services across all lifecycle states; the catalog publishes the subset that is requester-facing and active. Refer to the IF4IT Service Catalog Best Practices document for detailed catalog governance guidance. |
| Service Portfolio | The broader governed collection of Services managed by the organization or organizational unit across lifecycle states — Proposed, Planned, Designed, Piloted, Active, Deprecated, Retired, Rejected, and Under Review. The Service Portfolio is the strategic, lifecycle-aware view of all Services; the Service Catalog is the requester-facing view of the active subset. |
| Service Pipeline | The portion of the Service Portfolio containing proposed, planned, designed, or in-development Services that are not yet fully operational or approved for normal consumption. The Service Pipeline is the controlled path from Service idea to operational Service. |
| Service Group | A logical grouping of related Services — typically by fulfillment responsibility, service area, requester community, operational capability, or business context. Service Groups sit between individual Services and Service Portfolios in scale, and may have a Service Group Owner accountable for the group’s coherent governance. |
| Service Engagement Channel | An approved path through which Service Requesters interact with a Service to request, invoke, or consume it. Common Service Engagement Channels include the Service Catalog, departmental portals, workflow forms, API catalogs, automation platforms, chat interfaces, the Service Desk, and intranet pages. A single Service may be exposed through multiple Service Engagement Channels. |
| Service Record | A governed record of a single Service Request — the request itself, the action taken, the status, the evidence captured, and the outcome produced. Service Records are transactional, not definitional: the Services Inventory governs Service definitions; the Service Record system governs the operational instances of Services being invoked. Service Records are also informally known as Service Tickets. |
| Service Desk (a.k.a. Help Desk) | The operational function that receives Service Requests, performs initial triage and routing, fulfills simple Service Requests directly, escalates complex Service Requests to Subject Matter Expert teams, and serves as the front door for Service Management. The Service Desk is part of the Service Provider Workforce alongside Service Providers / Service Actors. |
| Subject Matter Expert (SME) Team | A specialist fulfillment team that handles complex Service Requests escalated from the Service Desk. SME Teams provide deeper technical or domain expertise than the Service Desk maintains directly. Distinct from Service Providers / Service Actors who handle routine fulfillment. |
| Service Governance | The discipline of overseeing the enterprise’s Services as a portfolio of governed assets — ensuring every Service has defined ownership, accountable lifecycle management, current Service Definitions, measurable performance, and clear connection to the broader Enterprise Model. The Services Inventory and the Service Catalog are peer governance instruments within Service Governance. |
| Service Lifecycle | The defined sequence of states a Service may pass through during its existence. The IF4IT Service Management Best Practices document defines nine canonical states: Proposed, Planned, Designed, Piloted, Active, Deprecated, Retired, Rejected, and Under Review. Lifecycle state is governed by the Service Owner and recorded in the Lifecycle Status attribute of every Service record. |
| Service Roadmap | The forward-looking plan for a Service — its planned evolution, improvements, capability additions, deprecations, and strategic direction. Every governed Service should have a Service Roadmap maintained by the Service Owner. Refer to the IF4IT Service Management Best Practices document for Service Roadmap governance guidance. |
| Service Inputs | What flows into a Service for it to function — data inputs, trigger inputs, resource inputs, material inputs, knowledge or instruction inputs, or any other inputs the Service consumes to produce its Service Outcomes. Captured as descriptive text in the Services Inventory and elaborated in formal interface specifications where they exist. |
| Service Outputs | What flows out of a Service as a result of its operation — data outputs, state changes, decisions, notifications, deliverables, transactions, or any other outputs the Service produces. Captured as descriptive text in the Services Inventory and elaborated in formal interface specifications where they exist. Distinct from Service Outcomes (which describe the result for the Service Requester); Service Outputs describe what the Service emits or changes regardless of who receives it. |
| Service Tier | The strategic importance classification of a Service to the enterprise. Common tier schemes: 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). Service Tier drives governance investment proportional to Service importance. |
| Service Delivery Mode | How a Service is delivered to its Service Requester Community. Common values: Human-Delivered (work performed primarily by people), Technology-Delivered (work performed primarily by automated systems), or Hybrid (a combination of human and technology delivery). |
| Service Consumption Mode | How a Service is engaged by its Service Requester Community. Common values: Requestable (the Service Requester submits a Service Request through a Service Engagement Channel), Invokable (the Service is triggered programmatically, typically through an API), Consumable (the Service is continuously available for direct use), or Subscribed (the Service Requester has standing access to the Service through a subscription). |
| Service Direction | Whether a Service is offered by the enterprise, consumed by the enterprise, or both. Common values: Internal-Provided (the enterprise offers the Service to internal Service Requesters), External-Provided (the enterprise offers the Service to external Service Requesters), Internal-Consumed (the enterprise consumes the Service from internal Service Providers), External-Consumed (the enterprise consumes the Service from external Service Providers — typically Vendors), or Both. |
| Service Engagement Owner | The role accountable for the accuracy and currency of a Service’s representation across its Service Engagement Channels — keeping descriptions, request links, required inputs, response expectations, and support paths consistent across the Service Catalog, portals, intranet pages, API catalog entries, chatbot answers, and other engagement surfaces. |
| Catalog Manager | The role accountable for the accuracy, currency, and structure of Service Catalog entries — a peer governance role to the Service Engagement Owner with specific accountability for the Service Catalog as a managed governance artifact. Refer to the IF4IT Service Catalog Best Practices document for Catalog Manager guidance. |
| Portfolio Owner | The role accountable for the overall health, strategic direction, investment, value, lifecycle balance, and performance of a Service Portfolio. Portfolio Owners govern at the portfolio level; individual Service Owners govern at the Service level. The two ownership levels are complementary, not redundant. |
| Service Group Owner | The role accountable for the coherent governance of a Service Group — typically a logical grouping of related Services. Service Group Owners coordinate cross-Service governance for the group, including consistency of Service Definitions, alignment of Service Expectations, and shared engagement standards. |
| Service Records Source | The authoritative system of record for the Service Records of a given Service — the platform (typically an ITSM tool, ticketing system, workflow platform, or API gateway log) where individual Service Request transactions are captured, tracked, and reported. |
| Service Completion Definition | The specific, governed definition of what completion means for a Service Outcome and Service Response. Completion definitions help Service Providers, Service Actors, Service Requesters, and Service Owners share a common understanding of when a Service Request is genuinely fulfilled rather than informally closed. |
| Fulfillment Responsibility Model | The structure that defines who performs Service Action work for a Service. Common values: Single-Team (one team fulfills all Service Requests), Multi-Team (multiple internal teams share fulfillment), Cross-Org (fulfillment crosses organizational boundaries), Vendor (a Vendor performs primary fulfillment), or Automated (a system or workflow performs primary fulfillment). |
How to cite this page
When referencing this page in academic work, internal standards, or external publications, include the page title, IF4IT as author and publisher (The International Foundation for Information Technology (IF4IT), LLC), the URL, and your access date.
Example (informal web citation):
The International Foundation for Information Technology (IF4IT), LLC. Glossary of Terms and Phrases | Services Inventory and Attributes. https://if4it.org/best-practices/services-inventory-and-attributes/glossary-of-terms-and-phrases/ (accessed 2026-07-23).
See About Us for content governance and site-wide citation guidance.
Copyright for The International Foundation for Information Technology (IF4IT), LLC: 2008 - Present
Legal Disclaimers