If you ask a customer, “What do you want?”, you might expect a useful answer. Sometimes you get one. More often, you get something like:
“I need a system that works.”
That sounds reasonable. But what does works mean? Does it need to be available 24 hours a day? Is an hour of downtime acceptable? Does it need to handle 10 users or 10,000? How much security is necessary? How much can the organization afford? What happens when the service isn’t available? What does the customer actually need to accomplish with it?
Those questions are where we start getting closer to value. Value is defined as the perceived benefits, usefulness, and importance of something. The customer determines value, but they rarely articulate every requirement, trade-off, risk, and desired result upfront. Customers often know what they value through experience, but they struggle to outline every technical spec or underlying constraint before a project begins. The questions above aren’t just a checklist; they are the tools a provider uses to help uncover that value.
To understand what creates value for a customer, service management weaves together several core concepts: utility, warranty, cost, risk, outputs, outcomes, user experience, sustainability, and service levels.
Value Starts with the Customer
Value is not determined solely by the service provider. A provider can build an impressive service, add features, achieve excellent technical performance, and still fail to provide the value the customer expected.
Consider a simple request:
“Make me a website.”
That’s not really enough information to build the right service. What kind of website?
- An online store?
- An informational website?
- A customer portal?
- A registration system?
- A website for employees?
Those are all websites, but they serve very different purposes. So instead of simply asking, “What do you want?”, we start asking better questions:
- What do you need the website to do?
- Who will use it?
- What are they trying to accomplish?
- What information does it need to protect?
- How available does it need to be?
- What happens if it isn’t available?
- How much can you spend?
- What risks are acceptable?
The customer may not have thought through all of those things when they asked for a website. But answering them helps reveal what the customer actually considers valuable.
Value Is Co-Created
Value isn’t simply something a provider produces and hands to a customer. The provider contributes its resources, capabilities, knowledge, and services. The service consumer also participates in the service relationship and uses the product or service. The resulting value emerges from what happens through that active relationship—synthesizing the service’s use, the resulting outcomes, and the trade-offs of cost and risk.
An output is a tangible or intangible deliverable of an activity.
An outcome is a result for a stakeholder, enabled by one or more outputs.
Imagine a service desk request:
“Reset my password.”
The service desk resets the password. That’s an output. But is that really what the customer wants? Probably not. They want access to the service. The customer thinks the password is the problem. Maybe it is. But perhaps the user entered the wrong user ID, the account is locked, the service itself is unavailable, or there is another authentication problem.
You can reset the password 100 times, but if the user still cannot access the service, the desired result hasn’t been achieved. The provider produced the requested output. The customer didn’t get the outcome. That distinction is fundamental to understanding value.
Utility: What Does the Service Do?
Utility is the functionality offered by a product or service to meet a particular need (fit for purpose). A simple way to think about utility is: What does the service do?
Notice that this is different from asking, “What is the service?” Consider the request: “Make me a website.” We still don’t know enough. Is it an ecommerce website where customers purchase products, or is it an informational website designed to provide information? Those services may use similar technology, but the functionality required is very different. Utility is about what the service does and whether it meets the intended purpose.
Warranty: Can We Rely on the Service?
Once we understand what the service needs to do (utility / fit for purpose), we have to evaluate how it performs (warranty / fit for use). Warranty is the assurance that a product or service will meet agreed requirements regarding how reliably and safely it operates.
Security
Security is an obvious example. Think about Wikipedia versus Bank of America. If Wikipedia were hacked or unavailable for 24 hours, it would certainly be inconvenient. If your bank account were compromised, the consequences could be dramatically different. The required security isn’t the same for every service. A provider needs to understand what information is involved, what the service does, and what level of security the customer requires.
Availability
How available does the service need to be? It is tempting to say: “All the time.” But there is a trade-off. Higher levels of availability can require additional investment. There is a point where the cost of achieving additional availability may no longer make sense for the customer. The question is: How available does this service actually need to be?
Capacity
How much demand does the service need to handle? A service needs enough capacity to meet expected demand, including periods of peak demand. For example, cloud infrastructure may need to scale dynamically when usage increases. Too little capacity can prevent the desired outcomes from being achieved; too much capacity can increase costs unnecessarily.
Continuity
And then there is a question organizations sometimes don’t consider until something breaks: What do we do when the service isn’t available? Consider automated reports. If an organization relies on an automated reporting service every morning and that service goes down, do employees know how to produce the reports manually? If the automated process fails, having an alternative procedure can allow the business to continue operating while the service is restored. That’s continuity.
Cost: What Is the Customer Willing to Invest?
Cost is obviously part of the value conversation. But cost is not value. A simple reality check: Cheap — or even free — means nothing if you’re not safe.
An IT service with no meaningful security controls might be extremely cheap. But if customer or non-public information is stolen, where is the value? The organization saved money, but it may have created risks that outweigh those savings.
At the same time, cost cannot simply be ignored. There is a point where the cost of providing a particular level of service becomes too high relative to the value the customer receives. The question isn’t: “What’s the cheapest option?” Nor is it: “What’s the most expensive option we can afford?” The better question is: What level of cost is acceptable for the value we need?
Risk: What Is the Customer Willing to Accept?
Risk works similarly. Risk is never zero; there is always some level of uncertainty. Consider software versions. Should an organization run the newest software version, stay one version behind, or continue using an older release? Each choice involves different costs and risks.
The newest version may provide new capabilities. Staying one version behind may provide a different balance between new functionality and change-related risk. Remaining on a much older version may reduce some immediate change-related risk while introducing other risks. Which option provides the most value? There isn’t one universal answer. The customer has a risk tolerance; what is acceptable for one organization may be completely unacceptable for another.
Cost and Risk Have to Be Considered Together
This is where value becomes more complicated:
- Reducing cost can increase risk.
- Reducing risk can increase cost.
- Increasing functionality can increase both.
- Reducing functionality can lower cost while also reducing the outcome the customer can achieve.
There is no magic point that applies to every organization. The goal is to understand the customer’s needs and find an appropriate balance between the benefits being sought, the costs involved, and the risks the customer is willing to accept.
User Experience
A service can have the right utility and warranty while still frustrating the people using it. User experience accounts for the sum of functional and emotional interactions with a service.
Consider an internal expense-reporting tool. It may technically do everything it is supposed to do. But if the interface is confusing, the process is frustrating, and employees struggle to figure out what to do, the experience is poor. The service can be technically functional and still fail to provide the experience users need. A service isn’t experienced only through its technical capabilities; people experience it through the interactions, processes, communications, and activities surrounding its use.
Sustainability
A service can provide value today while creating longer-term consequences that need to be considered. Sustainability brings environmental, social, and economic considerations into the service conversation. A service that works well today may still need to be evaluated in terms of its longer-term impact and ability to continue meeting the needs of the organization and its consumers.
Service Quality and Service Levels
Organizations also need a way to establish and manage expectations about service quality. This is where service levels and Service Level Agreements (SLAs) become important. A Service Level Agreement (SLA) is a documented agreement between a service provider and a customer that identifies the services provided and the agreed level of each service.
For digital services, SLAs should describe utility, warranty, and sustainability. When services are consumed by users, user-experience metrics should also be included. That gives both sides a shared understanding of what has been agreed.
The Important Point: Meeting an SLA target does not automatically mean the customer achieved the outcome they wanted. An agreed service level is one part of understanding service quality and value, but it does not guarantee that the desired business results were reached.
Bringing It All Together
The consumer determines value, but understanding what creates value isn’t always as simple as asking what they want. Consumers often know what they experience without being able to articulate every underlying requirement upfront.
Utility helps us understand what a service needs to do, while warranty tells us how well it performs. Cost and risk highlight the critical trade-offs involved. Outputs and outcomes distinguish what the provider delivers from what the consumer achieves. User experience, sustainability, and service levels add vital dimensions to the conversation.
None of these concepts, by itself, defines value. Together, they help the provider and consumer ask better questions and develop a clearer understanding of what a service needs to achieve in any given situation.
Ready to test your ITIL 5 knowledge? Take the ITIL 5 Foundation Practice Quiz or learn more about ITIL 5 Foundation training from Ashford Global.