What’s the Real Objective of Service Delivery?
In IT Service Management (ITSM), it’s easy to get caught up in frameworks, SLAs, and tooling. But strip away the jargon, and the objective of service delivery is straightforward, to do something for another party, for a defined period, because they can’t, won’t, or aren’t allowed to do it themselves.
That “something” isn’t just a task, it’s a facility, a blend of goods and actions made available to the customer, backed by ongoing support to keep it usable. It’s not a one-off transaction. It’s an ongoing relationship where continuity and reliability matter just as much as capability.
My reference to “Facility” above comes from Unified Service Management (USM). If you haven’t worked it out already I am a big fan. After spending 20+ years working with various frameworks, there is nothing that comes close to they way USM simplify’s Service Management.
Link – USM Wiki
Why does continuity matter so much?
Because dependency changes expectations. If a business relies on a cloud-based finance application, the conversation isn’t about whether it’s up today, it’s about ensuring it’s up tomorrow, next week, and next quarter. Customers expect that guarantee. Providers commit to it. Both sides must put in continuous effort to keep the service running, supported, and valuable over time.
Who’s actually involved?
I like to frame service delivery round three roles.
- Provider. delivers the service as agreed.
- Customer. decides whats procured and holds responsibility
- User. authorised to use the service.
In simple setups, the customer and user might be the same person. In more complex organisations, there might also be a sponsor, someone controlling the budget but not the operational details. Recognising and managing these roles clearly avoids the “too many cooks” problem when defining requirements.
What’s in it for the customer?
Value. But value isn’t created in isolation. In service-dominant logic, value comes from co-creation, the provider offers the facility and support, the customer uses it effectively. A high performing ITSM team might implement a self-service portal for password resets. On paper, it’s a technical success. But if the customer’s processes for onboarding staff are slow or unclear, the perceived value drops.
What’s in it for the provider?
Also value, but in a different form. That could be revenue, data, loyalty, or meeting contractual obligations. The exchange is two-way, resources, effort, and trust flow both directions. Service delivery fails when either party stops seeing the exchange as fair.
Why define “service” so carefully?
Because sloppy definitions lead to messy delivery. We need to remove circular definitions, service delivery is delivering services and focuses on components:
- A facility made available by the provider
- Support for using that facility
- Agreed continuity over time
From this, it easier to build clear service descriptions, service catalogues and operational agreements.
What’s the trap to avoid?
Thinking service is just about fixing things when they break. Historically, “good service” was shorthand for responsive support after delivery. Today, that’s only part of the picture. In ITSM, support is built into the service from the start, whether it’s proactive monitoring, automated scaling, or clear user guidance.
If the goal is to deliver sustained value, the question for any IT leader is this. Are we treating service delivery as a one-time act, or as a living commitment that evolves with the customer’s needs?
FAQ Questions
What’s the difference between a customer and a user in ITSM?
A customer agrees the service with the provider and is accountable for its use. A user is authorised to use the service but doesn’t set its terms unless the customer delegates that authority.
Why do I emphasise “supported facilities”?
Because a facility without support is a product, not a service. The support ensures the customer can keep using it as intended over time.
Is service delivery only about uptime?
No. Continuity is critical, but service delivery also covers usability, support, and agreed value outcomes. Uptime without usefulness still fails the customer.
Can value exist if the service isn’t being used?
No. Value is only realised through interaction, when users actively use the facility and the provider supports that use.