Service Management Best Practices - Glossary of Terms and Phrases
Service Management Best Practices
Chapter 2. Glossary of Terms and Phrases
Overview
The following glossary defines terms and phrases used throughout this document. Terms are listed in alphabetical order. All definitions are specific to the context of Service Management as described in this document.
| Term or Phrase | Abbreviation or Acronym | Definition |
|---|---|---|
| Accountable Owner | The individual or role responsible for the performance, value, governance, and continuous improvement of a service, product, portfolio, application, process, or other managed construct. | |
| API | API | An application programming interface that exposes a defined capability, data set, transaction, action, or service for consumption by another system, application, user interface, automation, or technology component. |
| API Gateway | A technical platform or control point used to expose, secure, route, monitor, throttle, and manage APIs that may provide or support technology-delivered services. | |
| Atomic Service | A coherent governed service that produces a specific reusable outcome and can be requested, invoked, consumed, orchestrated, or reused directly or as part of a larger compound service or Service Bundle. An atomic service has defined boundaries, accountable ownership, inputs, outputs, Service Expectations, fulfillment responsibilities, records or evidence requirements, and registration in the enterprise Services Inventory. | |
| Batch Processing Service | A technology-delivered service that performs scheduled, triggered, or event-driven processing work, usually without direct human interaction during execution. | |
| Batch Processing Service | A technology-delivered service that performs scheduled, triggered, or event-driven processing work, usually without direct human interaction during execution. | |
| Business Service Catalog | BSC | The requester-facing or customer-facing view of the Service Catalog that describes approved services in plain, outcome-oriented language focused on what the service does, who it is for, how to request or consume it, and what the requester can expect. The Business Service Catalog should be a governed view of the same underlying service definitions used by other service views, not a separate source of truth. |
| Catalog Manager | The individual, team, or role accountable for governing the accuracy, consistency, usability, and maintenance of Service Catalog entries and related service engagement content. | |
| Catch-All Service | A governed service or request option used to capture requests that do not fit a more specific published service entry. A catch-all service prevents requester dead ends, but it should create or update a Service Record, route to a responsible Service Group, and be reviewed as evidence for catalog, taxonomy, inventory, or service-definition improvement. | |
| Compound Service | A broader governed service that coordinates multiple atomic services, actors, approvals, workflows, records, communications, and outcomes to satisfy a larger requester, customer, consumer, or stakeholder need. A compound service may be exposed to requesters as a Service Bundle when multiple related services are packaged as one catalog-facing entry. | |
| Crawl / Walk / Run | CWR | An incremental maturity path used to help organizations start simply, mature deliberately, and scale responsibly. In this document, Crawl / Walk / Run helps small, midsized, and large organizations apply Service Management practices at an appropriate level of formality, tooling, automation, governance, and reporting. |
| Crawl / Walk / Run | CWR | An incremental maturity path used to help organizations start simply, mature deliberately, and scale responsibly. In this document, Crawl / Walk / Run helps small, midsized, and large organizations apply Service Management practices at an appropriate level of formality, tooling, automation, governance, and reporting. |
| Customer or Consumer | A person, group, organization, system, application, or technology component that receives, requests, invokes, uses, or consumes a service. | |
| Customer Segment | A defined group of customers, consumers, requesters, or stakeholders for whom a service is designed, exposed, delivered, supported, measured, or improved. | |
| Data / Information | Data, records, content, or information assets that may be created, used, updated, exchanged, reported, or consumed in the delivery of a service. Data and information may enable a service, but they are not automatically services. | |
| Enabling Construct | An application, API, process, platform, database, infrastructure component, workflow, automation, team, vendor, or other asset that supports, facilitates, or participates in service delivery but is not automatically a service itself. | |
| Enterprise Architecture | EA | The organizational discipline responsible for defining and governing the structures, standards, relationships, and strategies that guide how the enterprise uses business capabilities, information, applications, technologies, and services to achieve its goals. |
| Ephemeral Computing Service | A technology-delivered service that performs a defined function using temporary compute resources that are created, used, and then shut down or released after the work is complete. | |
| Fulfillment | The work performed to satisfy a Service Request, execute a Service Action, resolve an Incident, produce a Service Outcome, or deliver value to a requester, customer, consumer, or stakeholder. | |
| Governed Service | A service that is formally defined, owned, managed, measured, and controlled according to organizational expectations. A governed service has defined boundaries, customers or consumers, accountable ownership, Service Details, Service Expectations, request or consumption mechanisms, outcomes, and value. | |
| Help Desk | A support function, team, or engagement channel that receives, routes, fulfills, coordinates, or resolves service requests, incidents, questions, and support needs. In this document, Help Desk and Service Desk are treated as closely related practical terms, especially for small and mid-sized organizations, and are often the practical starting point for Service Management. | |
| Human-Delivered Service | A service primarily fulfilled by people, teams, organizational roles, or vendors. Examples may include consulting, planning, support, onboarding, quality assurance, change management, and incident recovery services. | |
| Incident | An unplanned interruption, degradation, failure, defect, error, or abnormal condition that affects a service, service outcome, user experience, application, infrastructure component, integration, network, or other enabling construct. | |
| Infrastructure | Hardware, networks, facilities, cloud resources, hosting environments, connectivity, and other foundational technology components that support applications, platforms, and services. Infrastructure may enable a service, but it is not automatically a service. | |
| Multi-Façade Service Catalog Architecture | A Service Catalog architecture in which multiple requester-facing or consumer-facing façades, portals, or domain views expose services to different communities while centralized governance is maintained through the enterprise Services Inventory, Service Portfolio hierarchy, common ownership rules, lifecycle controls, and Service Management standards. | |
| Other Service | A specific type of catch-all service entry within a service domain that allows requesters to submit needs that do not match a specific listed service. Other Service requests should be routed, recorded, reviewed, and used to identify missing services, unclear descriptions, taxonomy problems, duplicates, or improvement opportunities. | |
| Platform | A foundational technology or business capability that provides common functions, tools, infrastructure, integration, automation, data, or operating capabilities used by applications, processes, teams, or services. | |
| Portfolio Owner | The individual or role accountable for the health, strategy, value, investment priorities, lifecycle balance, risk posture, performance, and improvement direction of a Service Portfolio. | |
| Process | A structured set of activities, decisions, controls, workflows, roles, and outputs used to achieve a business or operational result. A process may support or participate in service delivery, but it is not automatically a service. | |
| Product Owner | In the context of Service as a Product, the individual or role accountable for the strategic direction, roadmap, prioritization, and value delivery of a specific service or service-related product. | |
| Reusable Service | A governed service that is designed so its outcome, workflow, automation, records, evidence, or fulfillment pattern can be reused consistently across multiple service journeys, Service Portfolios, customer segments, or operating domains. | |
| Service | A defined capability or offering that an organization provides to a defined customer, consumer, requester, or stakeholder to help them achieve a specific goal or outcome. A service has defined boundaries, accountable ownership, Service Expectations, a value proposition, and a defined means of request, fulfillment, delivery, invocation, or consumption. | |
| Service | A defined capability or offering that an organization provides to a defined customer, consumer, requester, or stakeholder to help them achieve a specific goal or outcome. A service has defined boundaries, accountable ownership, Service Expectations, a value proposition, and a defined means of request, fulfillment, delivery, invocation, or consumption. | |
| Service Action | The work performed by one or more Service Actors in response to a Service Request, trigger, input, incident, event, or consumption activity. | |
| Service Actor | A person, team, system, application, automation, platform, vendor, or technology component that performs a Service Action or participates in fulfillment, routing, escalation, communication, evidence capture, or outcome delivery. | |
| Service Agreement | A documented commitment, understanding, or agreement that defines service responsibilities, expectations, targets, assumptions, escalation paths, and consequences or responses when expectations are met or missed. | |
| Service Backlog | An ordered list of planned improvements, enhancements, defects, risks, automation opportunities, and changes to a specific service or service group. The backlog is usually managed by the Service Owner, Product Owner, or Service Manager based on customer value, operational need, and organizational impact. | |
| Service Boundary | The defined scope, limits, applicability, inclusions, exclusions, responsibilities, dependencies, and ownership edges of a service. Service boundaries clarify what the service does, what it does not do, who it serves, and where ownership begins and ends. | |
| Service Bundle | A catalog-facing package that presents two or more related services as a single requestable entry or customer journey. A Service Bundle simplifies the requester experience, such as onboarding that includes equipment provisioning, access provisioning, and orientation scheduling, while the underlying services remain separately governed, owned, recorded, measured, and reusable. | |
| Service Catalog | The requester-facing or consumer-facing facade, publication layer, or governed view through which approved services are discovered, understood, requested, invoked, or consumed. A Service Catalog exposes Service Details and Service Engagement Channels, but it is distinct from the enterprise Services Inventory that governs service records and from the Service Request Management Application that records and routes individual work items. | |
| Service Composition | The design practice of assembling atomic services, reusable workflows, actors, approvals, automations, records, communications, and Service Bundles into broader compound services while preserving ownership, Service Expectations, traceability, governance, and customer experience. | |
| Service Consumer | A person, group, organization, system, application, automation, or technology component that consumes or uses a service. A Service Consumer may or may not be the same as the Service Requester. | |
| Service Consumer | A person, group, organization, system, application, automation, or technology component that consumes or uses a service. A Service Consumer may or may not be the same as the Service Requester. | |
| Service Coverage | The defined scope of when, where, how, and for whom a service is supported, fulfilled, escalated, or available. Service Coverage may include business hours, after-hours support, holidays, locations, time zones, requester communities, channels, escalation paths, on-call expectations, and exceptions. | |
| Service Customer | The person, group, organization, or stakeholder for whom a service is designed, delivered, funded, governed, or measured. | |
| Service Definition Criteria | The required characteristics used to determine whether something qualifies as a governed service. Common criteria include defined boundaries, an identifiable customer or consumer, accountable ownership, a value proposition, expected outcomes, Service Expectations, and a means of request, fulfillment, delivery, invocation, or consumption. | |
| Service Desk | A support function, team, or engagement channel that provides a structured point of contact for service requests, incidents, questions, communications, routing, fulfillment coordination, and support. In this document, Service Desk and Help Desk are treated as closely related practical terms; the Service Desk or Help Desk is often the visible operating function through which Service Management is experienced. | |
| Service Details | The requester-facing and provider-facing information that explains what a service is, who it is for, what it provides, how to request or consume it, what inputs are required, what outcomes to expect, what boundaries apply, and how the service is supported. | |
| Service Engagement Channel | An approved channel through which a requester, customer, consumer, system, application, or automation discovers, requests, invokes, consumes, or interacts with a service. Examples include Service Catalogs, intranet pages, portals, forms, chat, email, phone, API catalogs, automation platforms, and workflow tools. | |
| Service Expectation | A defined expectation for how a service should behave, perform, respond, fulfill, communicate, and deliver outcomes. In this document, Service Expectations are composed of Service Indicators, Service Objectives, and Service Agreements. | |
| Service Facade | The requester-facing or consumer-facing presentation layer through which services are discovered, understood, requested, invoked, or consumed. A Service Facade may be implemented through one Service Catalog or through multiple coordinated domain portals, technical portals, API catalogs, or other engagement channels. It presents and initiates service interactions; it is not the authoritative Services Inventory and it is not the system of record for individual Service Requests. | |
| Service Governance | The organizational framework of policies, roles, accountabilities, standards, controls, decision rights, measures, and review practices that ensures services are properly defined, owned, managed, measured, improved, and aligned with organizational goals. | |
| Service Group | A logical collection of related services grouped by customer community, business function, fulfillment responsibility, technology domain, service area, operational capability, lifecycle stage, risk profile, or other useful management structure. | |
| Service Indicator | An observable or measurable signal used to understand service performance, quality, demand, behavior, risk, or outcome. Examples include response time, fulfillment time, request volume, backlog, reopen rate, customer satisfaction, availability, error rate, and automation success rate. | |
| Service Intake | The governed process or entry point through which Service Requests, Incidents, tasks, questions, approvals, or other service work are received, captured, classified, prioritized, routed, and recorded. Service Intake may occur through a Service Catalog, Help Desk, Service Desk, Ticketing System, form, email, phone, chat, API, automation, or other approved Service Engagement Channel. | |
| Service Level Agreement | SLA | A formal agreement that defines expected service performance, commitments, responsibilities, targets, measures, assumptions, escalation paths, and obligations between a service provider and a customer, consumer, or stakeholder. |
| Service Level Objective | SLO | A measurable target or objective that describes the expected level of performance for a service, such as availability, response time, resolution time, fulfillment time, throughput, quality, reliability, or customer satisfaction. |
| Service Management | The professional discipline of establishing and treating services as managed assets that deliver defined value to defined customers, consumers, requesters, or stakeholders. It encompasses service definition, governance, ownership, lifecycle management, catalog and portfolio management, fulfillment, measurement, reporting, and continuous improvement. | |
| Service Management Tool Sprawl | The proliferation of redundant, disconnected, or overlapping Service Management tools, portals, catalogs, inventories, workflows, reports, integrations, and automation platforms across teams or portfolios. Tool sprawl increases cost, fragments skills, weakens reporting, and makes enterprise governance more difficult. | |
| Service Manager | The role accountable for coordinating day-to-day operational delivery of a service, Service Group, queue, or fulfillment area. A Service Manager may manage assignments, escalations, handoffs, procedures, reporting, and operational performance, but does not necessarily replace the accountability of the Service Owner. | |
| Service Objective | A target, threshold, or goal for one or more Service Indicators. Service Objectives define the desired level of service performance, behavior, quality, timeliness, availability, or outcome. | |
| Service Outcome | The result produced by a Service Action according to the specifications, criteria, or expectations of the Service Request and Service Expectations. A Service Outcome may include a deliverable, completed transaction, changed state, notification, record update, restored capability, or other measurable result. | |
| Service Owner | The individual or role accountable for the definition, boundaries, value, Service Details, Service Expectations, lifecycle, performance, quality, governance, reporting, and continuous improvement of a specific service. | |
| Service Pipeline | The portion of the Service Portfolio used to manage candidate, proposed, planned, designed, or in-development services that are not yet approved for normal operational request, invocation, or consumption. Pipeline services should still be registered or tracked with enough metadata to support ownership, funding, design, approval, deferral, rejection, or transition into active service operation. | |
| Service Portfolio | A recursive hierarchical grouping of services and/or child Service Portfolios. A Service Portfolio may contain individual services, other Service Portfolios, or both. Common examples include domain-specific groupings such as the HR Service Portfolio, Finance Service Portfolio, IT Service Portfolio, and Project Management Service Portfolio; each may contain sub-portfolios such as IT Infrastructure Services or IT Application Services. The phrase “the Service Portfolio,” used with the definite article, refers to the enterprise-wide root portfolio that encompasses all Service Portfolios and, transitively, all governed services the organization manages. | |
| Service Provider | A person, team, organization, vendor, system, application, platform, or automation responsible for performing, coordinating, supporting, or delivering some part of service fulfillment. | |
| Service Provider Workforce | The people, teams, vendors, systems, applications, automations, platforms, or other Service Actors responsible for fulfilling Service Requests, performing Service Actions, managing handoffs, and producing Service Outcomes. | |
| Service Queue | A managed collection of Service Records, Tickets, requests, incidents, tasks, approvals, or fulfillment activities waiting for review, assignment, action, escalation, resolution, or closure. Service Queues help Service Managers, queue owners, and Service Providers manage workload, backlog, priority, aging, and performance. | |
| Service Record | The governed record used to capture, route, assign, track, update, evidence, report, and close the work associated with a Service Request, Incident, transaction, event, or related service activity. A Service Record is often called a ticket in Help Desk or Service Desk environments. | |
| Service Registration | The act of formally recording a service in an approved catalog, inventory, registry, portal, platform, or management system so it can be governed, discovered, requested, invoked, measured, reported, or managed. | |
| Service Request | A transaction in which a requester, customer, consumer, system, application, or automation asks for delivery, invocation, access, information, or action against a specific service. A Service Request is an individual work-triggering event, not a Service Catalog facade, Service Portfolio grouping, or Service Pipeline item. | |
| Service Request Management Application | An application, ticketing tool, workflow platform, or Service Management system used as the system of record for creating, routing, assigning, tracking, updating, reporting, and closing Service Records, Tickets, incidents, tasks, approvals, fulfillment actions, or related service activities. It is architecturally distinct from the Service Catalog or Service Facade even when packaged in the same vendor product. | |
| Service Requester | A person, organization, system, application, automation, or technology component that requests, triggers, invokes, or consumes a service. | |
| Service Response | A response, deliverable, notification, update, confirmation, transaction result, record update, changed state, or other output provided to a Service Requester or Consumer after a Service Action is performed or a service interaction reaches a defined state. | |
| Service Review | A recurring operational or governance review used to assess service demand, performance, quality, risk, cost, value, backlog, customer feedback, incidents, fulfillment results, improvement opportunities, and lifecycle health. Service Reviews help Service Owners, Service Managers, and stakeholders decide what should be improved, escalated, funded, automated, changed, or retired. | |
| Service Value Proposition | A clear statement of the value, benefit, result, or outcome that a service provides to its intended customers, consumers, requesters, or stakeholders. | |
| Services Inventory | The enterprise-wide governance registry that records every governed service the organization delivers or manages. It is distinct from the Service Catalog facade, which publishes approved services for requester access, and from the Service Request Management Application, which records individual tickets or work items. Each service in the Services Inventory should be placed within the Service Portfolio hierarchy, tagged to its named Service Owner and Service Group, tracked through its lifecycle state, and described with the metadata needed for governance, reporting, transparency, catalog exposure, rationalization, and continuous improvement. | |
| Shared Service Management Platform | A common platform, toolset, or integrated set of capabilities used to support request intake, Service Records, Service Catalog entries, Services Inventory data, workflows, approvals, knowledge, automation, reporting, and governance across multiple services, teams, groups, or portfolios. | |
| Subject Matter Expert Team | SME Team | A specialized team or group of experts that supports or fulfills complex, high-risk, exception-based, or domain-specific Service Requests that require deeper knowledge than the primary Service Desk, Help Desk, or standard Service Provider workforce can provide. |
| Support Hours | The defined hours or time windows during which support, intake, fulfillment, communication, escalation, or on-call response is available for a service. Support Hours may include standard business hours, extended hours, after-hours coverage, weekend coverage, holiday rules, emergency support, and location or time-zone-specific availability. | |
| System of Record | The authoritative application, platform, database, workflow system, ticketing system, registry, or record store used to create, maintain, govern, and report the official record for a defined type of service activity or information. | |
| Technical Service | A service that is primarily delivered, invoked, or fulfilled through technology, automation, systems, APIs, platforms, batch processing, event processing, infrastructure, or other technical mechanisms. | |
| Technical Service Catalog | TSC | The fulfillment-facing or provider-facing view of the Service Catalog that includes operational, technical, dependency, routing, support, automation, and fulfillment information needed by Service Managers, Service Providers, Service Actors, architects, and operations teams. It should be a governed view of the same underlying service definitions used by the Business Service Catalog, not a separate catalog of record. |
| Technology-Delivered Service | A service primarily fulfilled by systems, applications, APIs, automation, scripts, workflows, platforms, or other technologies, with limited or no direct human involvement during execution. | |
| Ticket | A commonly used term for a Service Record. A ticket captures and tracks a specific request, incident, task, fulfillment activity, communication, action, status, evidence, and outcome. A ticket is not the service itself. | |
| Ticketing System | A commonly used term for the application, platform, workflow tool, or Service Request Management Application used to create, route, assign, track, update, report, and close Tickets or Service Records. In many Help Desk and Service Desk environments, the Ticketing System is the practical system through which Service Management work first becomes visible and measurable; it is not the Service Catalog and it is not the service itself. | |
| Ungoverned Sprawl | The uncontrolled proliferation of service portals, catalog entries, request paths, tools, service lists, workflows, or local practices without a common Services Inventory, shared governance, clear ownership, lifecycle control, and reporting. Ungoverned sprawl creates duplicate services, conflicting Service Details, weak accountability, poor transparency, and avoidable operational waste. | |
| Value Proposition | The specific value, benefit, result, or outcome that a service, product, capability, or offering is expected to deliver to its intended customer, consumer, requester, or stakeholder. | |
| Workflow / Automation | A structured sequence of automated or semi-automated steps used to perform work, coordinate activities, route requests, enforce rules, capture evidence, or produce outcomes. Workflow and automation may support services, but they are not automatically services. |
Terms and Definitions
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 | Service Management Best Practices. https://if4it.org/best-practices/service-management/glossary-of-terms-and-phrases/ (accessed 2026-07-28).
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