Service

What Is Service?

A service is a means of delivering value to customers by facilitating outcomes they want to achieve without owning specific costs and risks. In ITSM and ESM contexts, a service represents a structured offering—such as email access, laptop provisioning, password resets, or HR onboarding—that IT or another business function provides to internal users or external customers. Services are defined in a service catalog, governed by SLAs, and supported by underlying processes, assets, and teams. Unlike individual tasks or tickets, a service is the complete capability delivered to the end user, including availability, performance, support, and continuous improvement.

Services abstract complexity. When an employee requests a new laptop, they consume a service; they don't need to know which procurement system, asset database, or approval workflow operates behind the scenes. This abstraction allows organizations to standardize delivery, measure performance consistently, and scale operations without exposing users to operational detail.

Why Service Matters

Services are the fundamental unit of value delivery in IT and enterprise operations. Without clearly defined services, organizations struggle to measure performance, assign accountability, or communicate expectations. Users experience inconsistent support, teams duplicate effort, and leadership lacks visibility into what IT actually delivers versus what it costs.

Well-defined services enable SLA management. You can't measure uptime, response time, or resolution speed without knowing which service is being measured. Services also drive automation and self-service: a structured service catalog allows users to request what they need through a portal, triggering workflows that route, approve, and fulfill requests without manual handoffs.

For incident and problem management, services provide the context for impact assessment. When email is down, the service definition tells you how many users are affected, which business processes depend on it, and what the financial or reputational cost of downtime is. This context determines priority, escalation, and communication strategy.

Services also support financial transparency. By mapping costs to services—infrastructure, licenses, labor, vendor contracts—organizations can calculate total cost of ownership, compare internal delivery against outsourcing, and make informed investment decisions. Without service-level cost visibility, IT remains a black box.

How Service Works

A service is defined through several components: a service description, service owner, service catalog entry, SLA targets, supporting processes, and underlying configuration items (CIs). The service owner is accountable for performance and continuous improvement. The service catalog publishes available services to users, often with request forms, approval workflows, and fulfillment automation.

When a user requests a service, the request enters the service request management process. The system routes the request based on service definition rules—who approves, who fulfills, what steps are required. For example, requesting VPN access might trigger an automated approval from the user's manager, provisioning in the identity system, and a confirmation email, all orchestrated by the service definition.

Services are supported by underlying assets and processes tracked in a CMDB. The email service depends on mail servers, network infrastructure, DNS, and monitoring tools. When an incident affects one of these CIs, the service mapping shows which services are impacted, allowing the service desk to communicate accurately to users and prioritize restoration work.

Service level management continuously monitors service performance against SLA targets—uptime, response time, resolution time, availability windows. Breaches trigger alerts, escalations, and reviews. Over time, service performance data informs capacity planning, process improvement, and investment prioritization.

H2 Examples of Service

-  Email and Collaboration Service : A mid-sized enterprise defines email as a service with 99.9% uptime, 24/7 availability, and 4-hour response time for critical issues. The service includes mailbox provisioning, spam filtering, mobile access, and calendar sharing. When a mail server fails, the incident is logged against the email service, triggering automated status page updates and prioritized response based on the service's business criticality.

-  Employee Onboarding Service : An HR and IT shared service provides new hire onboarding, including laptop provisioning, account creation, access requests, and orientation scheduling. The service is defined in the ESM catalog with a 3-day fulfillment SLA. When a manager submits an onboarding request, workflows automatically route tasks to IT, facilities, and HR, track completion, and notify the hiring manager when the new employee is ready to start.

-  Managed Security Service for MSPs : A managed service provider offers 24/7 security monitoring as a service to multiple clients. Each client has a dedicated service instance with defined scope (endpoints monitored, alert thresholds, response times) and SLA commitments. The MSP uses service-level reporting to demonstrate compliance, justify pricing, and identify clients who need additional security investment based on incident trends.

Related Terms

- Service Catalog
- Service Level Agreement
- Service Desk
- Service Owner
- Service Request Management

---

Frequently Asked Questions

• How granular should a service definition be — when does breaking services into smaller units actually hurt more than it helps?
  Over-segmenting services creates catalog sprawl where users can't find what they need and teams spend more time maintaining service definitions than delivering value. A practical threshold: if two offerings share the same SLA targets, service owner, and fulfillment team, they belong under one service with request type variants rather than separate catalog entries. Consolidate until each service represents a distinct user outcome with measurable, independently governed performance.
• What's the difference between a service and a product in an ITSM context, and does the distinction actually matter operationally?
  A product is a deployable asset or software package; a service is the ongoing capability built around it, including support, availability commitments, and continuous improvement cycles. The distinction matters because accountability differs — a product owner ships releases, while a service owner is accountable for runtime performance and user experience after deployment. Conflating the two leads to gaps where incidents fall between teams because no one owns the operational layer.
• We have dozens of informal services that teams deliver without any catalog entry or SLA. What's the risk of leaving them undocumented?
  A: Undocumented services create invisible dependencies: when the team delivering them reorganizes or loses headcount, the service degrades or disappears with no visibility into downstream business impact. Without a catalog entry, you also have no mechanism to enforce consistent fulfillment, measure request volume, or justify resourcing during budget cycles. Shadow services are the most common source of unplanned outages that never get properly post-mortemed because no one formally owned the affected capability.
• How do you handle service ownership when a service spans multiple teams — like an onboarding service that involves IT, HR, and Facilities?
  Assign a single named service owner who is accountable for end-to-end SLA performance, even if fulfillment tasks distribute across teams — accountability cannot be shared without becoming no one's responsibility. Each contributing team owns their task SLA within the broader service SLA, and the service owner monitors aggregate completion to catch handoff failures before they breach the user-facing commitment. Without this structure, cross-functional services consistently fail at team boundaries where no one has authority to escalate across department lines.
• When should an organization retire or deprecate a service rather than just letting it quietly fall out of use?
  A service with active catalog entries and SLA commitments that stops receiving investment creates a compliance liability — users submit requests against SLAs the team can no longer meet, and incidents against the service skew performance reporting. Formal deprecation requires communicating a sunset date to users, migrating open requests to replacement services, and archiving the service record in the CMDB so historical incident and cost data remains queryable. Skipping formal retirement leaves orphaned CIs, unresolved tickets, and SLA breach records that distort service performance metrics for years.