CHAPTER 5
STEP 3: OFFER
5 Step 3: Offer
Having obtained a closer service relationship, the customer and the service provider can further shape customer demand and service offerings. The offer step helps the customer to articulate its needs and demands and the service provider to design matching service offerings. This chapter describes the service interactions and touchpoints needed for qualifying, designing, selling, and obtaining products and services based on value-driven, data-driven, and user-centred service design. The guidance applies whether the services are from an internal or an external service provider. Table 5.1 outlines the purpose of shaping demand and service offerings.
Table 5.1 The purpose of shaping demand and service offerings
Offer |
For the service consumer |
For the service provider |
Facilitate outcome and experience |
To ensure that the customer articulates the true needs and demands of the service consumer |
To understand how value is created for and with the service consumer and how the service provider can support this value co-creation To enable the service provider to balance supply and demand |
Optimize risk and compliance |
To minimize the risk of buying services and not fulfilling a real need To reduce the risk that the supplier misunderstands the consumer’s needs |
To minimize the risk of promising services they cannot fulfil To minimize the risk of unhappy customers |
Optimize resources and minimize cost |
To ensure money is invested in areas that optimize return of investment |
To ensure time and resources are used in the optimum areas |
The ITIL story: Step 3 – Offer
|
Mariana: Our eCampus Car Share service has been welcomed by students and staff of the university. We offer a subscription membership for regular car users, and different pricing tiers for intermittent users. Our cars are electric, which makes them a more environmentally sustainable option than traditional cars because they release fewer emissions overall. Plus, car-sharing results in lower rates of car ownership, fewer cars on the roads, and fewer car trips as customers combine their errands into one trip to maximize their spend. We pride ourselves on offering a clean, safe, and reliable alternative to other commuting options to and from campus. |
5.1 Managing demand and opportunities
For services, demand and capacity are interconnected. Services cannot be stored for later use. Service value can only be co-created when the service provider’s supply meets the service consumer’s demand. If the demand is not met, facilities and resources are wasted. Equally, there are lost opportunities when the demand is higher than the capacity. To optimize service opportunities, service providers should adjust capacity and influence demand. A proper understanding of how their services are being used by different customer groups and segments is crucial.
5.1.1 Patterns of business activity
To understand how services are being used, it is useful to analyse the patterns of business activity. Facts and charts are produced through monitoring and logging, reflecting the service usage. This information will allow measures to be implemented to meet peaks in demand.
Definition: Pattern of business activity (PBA)
A workload profile of one or more business activities. PBAs are used to help the service provider understand and support different levels of service consumer activity.
Table 5.2 describes a PBA for an accounting process.
Table 5.2 Example of pattern of business activity for an accounting process
Role |
Activity creating peak workload |
Time of the peak |
Employees |
All employees filling in timesheets |
Every Friday after lunch |
Accountant |
Accounting, reporting, and quality checks preparing for salary payment |
12th to 15th of each month |
Accountant |
Year-end accounting |
Every November/December |
Another pattern that can be identified is through analysing incoming calls. For example, the results can show that an average of 85 per cent of all support requests are made during two short periods each working day: 10.00–11.00 and 15.00–16.00. The service desk can also see the particular service required. With this information, the service desk can manage the demand by providing extra staff during peak times or creating a self-service solution.
Patterns of business activity are useful because they allow the organization to make fact-based decisions. The patterns detected can reflect different trends. Some patterns are repetitive, like the examples in Table 5.2; other patterns show growth or decline. Some services experience a rapid growth, which will have an impact on capacity. Further business analysis is required to understand the overall picture and make the right decisions.
Once the patterns are identified, different options will be available for adjusting and managing capacity and shaping demand.
Capacity and performance management practice
Capacity and performance management practice provides three perspectives on capacity management:
• Business capacity management plans for the capacity demand triggered by the customer.
• Product and service capacity management manages the end-to-end capacity of a particular product or service.
• Component capacity management monitors and tunes the capacity of the components of a product or service. If one of these components has no more capacity, the full service will suffer. In IT, most components can be set up with monitoring and tuning to avoid capacity issues.
Readers should refer to the capacity and performance management practice guide for more details.
As capacity and demand are intertwined, both must be considered in order to utilize scarce resources better. Managing demand is about understanding different user profiles and influencing their behaviour; capacity and performance management represents the other side of the equation. It is about sizing the capacity to respond to the actual demand, as illustrated in Figure 5.1.
There are many methods for sizing and managing capacity. Some measures include:
• increasing capacity during peak periods
• avoiding running other heavy workloads during the peak hours
• introducing freeze periods when changing a product or service is not allowed.
Demand can be fixed or variable. If demand is variable, the best course of action may be to match it with variable capacity in order to help the service consumer turn fixed costs into variable costs. This is how cloud computing usually works. Customers, such as a development team, use flexible self-service mechanisms to add additional infrastructure capacity exactly when they need it and release it when the job is done, making the capacity available for others.
Another way of optimizing resource capacity is to transfer the workload to the service consumer. This is relevant when designing technology services for digital transformation. Digital services allow service consumers to manage their own bank accounts, order tickets online, and book their own flights and hotels in order to offload the service provider’s demand and increase the service consumer’s control over the service.
Figure 5.1 Relationship between demand, capacity, and supply
5.1.3 Shaping or smoothing demand
Service providers are often challenged by large variations in service demand and limited capacity. Failing to shape the demand to match the supply will cause a poor return on capacity investments. For example, a service desk has a limited number of trained support staff. Smoothing demand to match the service capacity is therefore an important discipline.
Booking services that allow the service consumer to book time in advance help to smooth demand. To minimize loss, monitoring the rate of missed appointments and compensating with overbooking at a similar rate is common. Service providers often prevent the risk of no-shows by delaying the commitment on their side, adding a cancellation fee, or sending a reminder to ensure that the consumer confirms their booking a day in advance.
Service providers often offer price incentives to influence consumer behaviour. Differential charging is charging different prices for the same service based on the time of use. For example, an electricity company may charge different prices at different times of the day. The cheapest time to charge an electric car may be at night. This way, the operator can influence the service capacity during the day and simultaneously achieve better utilization during off-peak hours.
Yield management is a technique that uses price incentives to optimize capacity. It is a highly automated process that uses historical and real-time data to estimate future demand and adjust prices accordingly. For example, when browsing the internet for an upcoming trip, the price may be relatively low if it is searched for a few months in advance. However, the price for the same trip will increase significantly as the travel date approaches.
5.1.3.1 Pricing and charging mechanisms
Differential charging and yield management are examples of using pricing and charging mechanisms for managing capacity and demand. These mechanisms can be used to drive service consumer behaviour in many aspects of a service. Since it is such a powerful tool, it should be used consciously to drive the right behaviour. For example, if a cloud service provider wants its service consumers to clear the capacity when they no longer need it, a ‘pay per unit’ policy will influence the behaviour in the right direction.
There are adverse side-effects of charging being used as a demand management mechanism. Some examples of these side-effects are shown in Table 5.3. A proper evaluation and test should be performed to ensure that pricing mechanisms drive desired behaviour. This is supported by the guiding principles of think and work holistically and progress iteratively with feedback.
In a service relationship, pricing and charging mechanisms should be assessed and evaluated frequently to confirm that they work as intended. These mechanisms are often agreed during the contract negotiation phase, without much understanding of how they will affect behaviour and value creation.
Some important questions to ask are:
• Are the mechanisms driving behaviour in a way that optimizes value for both parties?
• Do the mechanisms allow for win-win and optimal use of resources?
• Are there incentives in place for both parties to drive service improvements?
Table 5.3 Examples of adverse side-effects of charging mechanisms
5.1.3.2 Service improvement opportunities
Service quality depends on the management of improvement opportunities. Conflicting requests from customers, poor pricing incentives, or a lack of a dedicated improvement budget could be sources of conflict. Therefore, the service provider must handle improvement opportunities professionally. Continual improvement requires ownership, a service improvement budget, and a transparent process to determine how improvement opportunities are identified, captured, assessed, prioritized, and handled.
Service improvement opportunities can come from a wide range of sources. Some examples include:
• service usage analytics
• incident, complaint, and problem analysis
• analysis of service request patterns
• analysis of self-service patterns and usage of knowledge articles
• change requests and improvement requests
• user feedback
• customer feedback and customer satisfaction surveys
• increased service demand
• new technology and innovation
• changes in the market
• feedback from service provider teams.
The objective is to gather facts about how a service facilitates value for stakeholders. This is an aspect of value-driven and data-driven insights. A business analyst may assist in the analysis of the data, identify needs, articulate requirements, and recommend solutions. The analysis should be based on real data captured regularly and frequently. To gain a greater understanding and make the right decisions, an in-depth business analysis is required.
Detailed guidance on how to accomplish structured service improvements is covered in the continual improvement practice guide and in ITIL ® 4: Direct, Plan and Improve. Tasks and techniques for performing business analyses are described in the business analysis practice guide.
5.1.4 Building the customer business case
When needs and demand are understood and addressed, a business case for meeting the demand through new or changed products and services may be drafted.8
Definition: Business case
A justification for the expenditure of organizational resources, providing information about costs, benefits, options, risks, and issues.
The core of a business case is a financial analysis evaluating an expenditure for profitability and risk. This analysis should consider both qualitative and quantitative aspects. A positive business case indicates that the expected benefits exceed the expenditures and risks.
A service business case should ideally cover all the areas of a full service, from service consumer purposes to products and resources, as shown in Figure 1.11. It should include all relevant benefits, costs, and risks.
The main questions to be covered in a business case include:
• What is the purpose?
• How does this new or changed service support the organization’s strategic goals?
• What is the problem to be solved?
• What is the desired outcome?
• Who are the stakeholders and how will it affect them?
• What are the expected benefits and disadvantages?
• What resources and investments are needed?
• What is the budget and the expected cost?
• What are the risks?
• What is the timeline for the process?
• When do we need resources and investments?
• What will be the total cost of ownership (TCO)?
• What is the expected return on investment (ROI) or net present value (NPV)?
• What organizational changes are needed in order to create value and realize the benefits?
The purpose of a business case is to establish a foundation for informed decision-making, but it is based on assumptions. These assumptions are subject to uncertainty and often conflicting needs and interests. Different perspectives affect the business analyst’s ability to prioritize the consumer requirements. Typical areas of conflict and uncertainty are highlighted in Table 5.4.
Table 5.4 Examples of typical areas of conflict and uncertainty
Areas for investigation |
Typical examples of conflicting areas within an organization |
Value Understanding real needs |
Who are the key stakeholders, and how are their needs prioritized? The users of the service may have different needs and priorities from the customer/sponsor (see Table 5.5). Other stakeholder groups may also have conflicting needs. |
Outcome Understanding benefits |
It may be tempting to focus solely on short-term benefits at the expense of longer-term benefits. On the other hand, long-term benefits are typically subject to more uncertainty and risk. |
Cost Understanding capital and operating expenses |
What kind of investment do we need for this product or service? What is the implementation cost? What is the maintenance and support cost? What is the cost of usage? How much training is needed? What kind of organizational change is needed? |
Risk Understanding uncertainty and impact |
It is difficult to know in advance whether a service provider is willing and able to fulfil the needs of the service consumer. It is important to establish a good relationship from the start, not only with the sales people, but also with the people who will be key resources for service provision. It is good to include incentives for relationship building and a win-win culture in agreements and contracts. |
Some traditional areas of conflicting priorities and needs are described in Table 5.5.
Table 5.5 Conflicting customer and user priorities and needs
A short-term focus on time and cost may impose significant costs later:
• Not enough time If there is not enough time to involve users, it can lead to their needs not being met. Therefore, the service may not enable the users to do a better job and may lead to a negative business case.
• Choosing the cheapest provider In this case, there is a great pressure on price and cost, which can leave the service provider with small margins and can prevent the service provider from being flexible without losing money. This may lead to a tense relationship focused on cost at the expense of value.
5.1.5 Building the service provider business case
The service provider needs to build and maintain a profitable and viable business case. Otherwise, the service provider may lose money and eventually go out of business. When building the business case, the service provider should consider the customers’ business cases.
When preparing a business case for a service, it is important to identify how the service fits into the existing and future portfolio of services. The portfolio management and financial management practices are key resources in this work.
A service is a means of enabling value co-creation by facilitating outcomes that customers want to achieve without the customer having to manage specific costs and risks. Risks are transferred to the service provider as part of the service.
To establish a business case, the service provider needs to understand the cost of providing a service. To do this, it needs to have a cost model that considers all the resources required. Analysing the cost elements in all four dimensions of service management may be helpful. This can include the following:
• investment and management of the technology and infrastructure that the services depend on
• value streams and processes needed to operate the service and facilitate the desired outcome
• partners and suppliers that will be part of the service provision
• organizational aspects, such as the number of resources and the skills and competencies of the staff.
Many ITIL management practices can provide input to a business case for a new or changed service for a customer organization and a service provider. These include:
• availability management
• capacity and performance management
• information security management
• portfolio management
• relationship management
• service continuity management
• service financial management.
The ITIL story: Managing demand and opportunities
|
Mariana: We have analysed patterns of business activity for our service and found that demand is highest during weeks in the middle of the term, but lowest during holiday periods. Weekend demand is lower than weekday demand. Evening use was popular but has dropped off in recent months. We attribute this to a local government campaign targeting students about the dangers of driving under the influence of alcohol or drugs. |
|
Solmaz: We can influence and create demand for the services we provide. For example, we offer discounted rates on car hire during non-peak periods, so we can shift some demand to those times. This helps with our capacity planning at busier times. |
|
Radhika: We have identified two busy periods for our service desk: the beginning of the academic year, when customers are signing up for a monthly subscription, and the end of the year when they are requesting refunds of the residual fees they have paid for their monthly memberships. During these times, we increase our resourcing for the service desk. |
5.2 Specifying and managing customer requirements
Requirement specification should occur within the band of visibility. Ideally, the customer should involve the service provider in an open and transparent requirement specification process. If requirements are sealed too early in the process, the service provider may be unable to shape the best possible service and meet the service consumer needs.
Many organizations use business analysts to engage with stakeholders to elicit and analyse requirements on behalf of the service provider or the service consumer. Business analysts will use many of the techniques described in this section. The business analysis practice guide provides guidance on this topic.
Definition: Business analysis
The practice of analysing a business or some element of a business, defining its needs and recommending solutions to address these needs and/or solve a business problem, and create value for stakeholders. Business analysis enables an organization to communicate its needs in a meaningful way, express the rationale for change, and design and describe solutions that enable value creation in alignment with the organization’s objectives.
The ITIL story: Specifying and managing customer requirements
|
Mariana: We have discovered a new customer requirement: many of our customers have to move house during the year. When they use our cars for this purpose, they need to make multiple trips and charge the cars more frequently than usual. They also return the cars with a reduced electric charge, making it difficult to hire out the car to the next customer. Plus, it compromises our vision of providing an environmentally sustainable service. |
|
Tomas: I encouraged Mariana to collaborate with Axle Car Hire to make trailers available to customers so that they could minimize the number of trips they were making. |
|
Katrina: My housemates have left university to head home to Europe, making it the second time I have had to move in two months! It is great that eCampus Car Share has identified the occasional need for a trailer to help customers move house. Now I do not have to find another option. |
5.2.1 Roles and responsibilities
Clear roles and responsibilities are key to specifying and managing requirements. Those in authority must be identified and show how user needs and expectations are captured, articulated, and represented.
In larger organizations, customers and users are sometimes separate. As a result, expectations and requirements may not be coordinated and aligned, as shown in Figure 5.2.
Figure 5.2 The service delivery triangle: the roles involved in transforming needs into requirements
The fact that requirements are negotiated and agreed between the service provider and the customer may be a challenge. To manage the perceived service quality, expectations and requirements have to be managed. Therefore, the service provider may become a mediator between customers and users. To prevent this from happening, the service consumer needs to embrace effective communication and coordination measures.
Table 5.6 illustrates a few scenarios for the orchestration of roles and responsibilities involved in service requirement specification.
Table 5.6 Examples of service consumer roles and requirement specification scenarios
Scenario |
Involved roles |
A customer orders a pre-defined standard service/product from a service provider, such as a laptop, smartphone, or app. |
The customer selects the standard service from a service provider based on a requirement specification. Representative users are consulted as part of the requirement specification. Based on their individual requirements, the users then choose between pre-defined alternatives. |
A customer obtains an off-the-shelf service from a provider to be configured, implemented, and managed internally in the service consumer organization. |
The customer conducts a proper evaluation upfront, to ensure a service that fits the needs of the service consumer. The customer evaluates whether it is fit for purpose and use. Even though it is an off-the-shelf service, there may still be many configuration options. Representative users of the service are therefore involved in the requirement specification and implementation. Other stakeholders, such as an internal IT department, contribute with non-functional requirements for the architectural fit and integration with existing infrastructure. |
A service provider develops a new and innovative service for or on behalf of a customer. |
To successfully develop a complex new service, an Agile approach to requirements specification is considered in order to: • iteratively break down complexity • build in technical requirements, such as security, from the start • involve the customer and ensure frequent feedback loops. This approach requires active customer participation throughout product development. For success, it is important that the customer (for example, a product owner) has the authority to make decisions on behalf of the service consumer on requirements and prioritization. Users may be consulted or even involved in kick-offs, demos, etc. |
A service provider designs a new commodity service for the mass market. |
Requirements are owned and managed by the service provider, who may or may not involve the service consumers in the transformation of needs into requirements. |
A business analyst may help to articulate and prioritize requirements and translate them into a language and format that a service provider can understand. This can be used as a basis for designing and building the service.
Requirements should not only be specified, but also be managed and tracked throughout the process. The requirement owners are responsible for:
• identifying stakeholder groups and representatives
• educating representatives in articulating requirements on behalf of their stakeholder groups
• collecting, documenting, managing, tracking, and communicating requirements
• continually ensuring that requirements are interpreted and understood in the correct way
• validating that products and services meet the requirements.
Customer requirements are not static; as new knowledge and experience is gained, customer needs change. Therefore, it is important to ensure requirements are focused on customer needs to make the time between the definition of a requirement and the testing of a product or service as short as possible.
Requirements must be testable. It is, therefore, important to define how to test whether requirements are met. In test-driven development, requirements are even defined by the tests they must pass in order to be considered met.
Utility requirements ensure that a new or changed product or service is fit for purpose. Utility requirements cover data, information, and functionality requirements.
Non-functional requirements ensure that a new or changed product or service is fit to use within the restrictions. Categories of non-functional requirements include but are not limited to:
• usability
• availability and reliability
• capacity and performance
• information security
• compliance
• continuity
• maintainability
• operability
• measurability and reportability
• scalability.
5.2.3 Separating the problem from the solution
We have already stated that requirements should be based on stakeholder needs. However, it may be tempting to specify a solution instead of translating needs into requirements. When articulating requirements, the problem must be separated from the solution in order to take account of the fact that solutions do not solve underlying problems. This also helps to separate current solutions from all the possible future solutions. Table 5.7 outlines a simple technique to help with this process.
Table 5.8 shows an example of this technique being used for a library service. Additionally, techniques such as refinement, mock-ups, and demos can help stakeholders ensure that they actually solve the underlying problem.
Table 5.7 A problem specification technique
Now |
Future | |
What? |
The current essence of the problem and the essence of what needs to be done |
What is the real need? What is ‘the essence’? |
How? |
The current way to perform the needed work |
What are possible ways to solve the problem in the future? |
Table 5.8 Example use of the problem specification technique
Now |
Future | |
What? |
A person needs to read a specific book. |
A person needs to learn about a specific topic. |
How? |
Go to a library and ask the librarian. The librarian uses a database to locate the book and register the loan. |
A lot of different ways are possible when we identify the essence of the problem and explore different ways of solving it, including online reading, audio-books, related articles, and summaries of the content. |
In the Lean startup approach described by Eric Ries (Ries, 2011), the key message is to make a prototype of a good business case and test it on real users in order to obtain feedback. For the prototyping, he relied on the concept of the minimum viable product.
A minimum viable product is a product with just enough features to satisfy early customers and to provide feedback for future product development. The concept is widely used in Agile development: the service provider envisages the minimal viable product for a specific need and specifies the requirements accordingly, then develops the product and delivers it to the users to gather feedback. The feedback is used to articulate future requirements and, through an iterative approach, the product will develop according to needs and priorities.
Key message
Emerging technologies, such as cloud computing, big data, automation, robotics, IoT, and AI, require emerging products and services. Concepts such as minimum viable product and Agile development enable emerging digital products and services.
The ITIL story: Minimum viable product
|
Mariana: For our trailer rental, the minimum viable product will not include any automation, such as tracking or online booking. Customers will need to book the trailers manually while we test and prove our concept. |
|
Tomas: Using an iterative approach, Mariana discovered that customers also need trolleys as part of the product offering. This was something she had not considered before trialling the trailer rental. |
5.2.5 User stories and story mapping
User story mapping is a common method of articulating service requirements. A user story is a way of representing areas of functionality required by the stakeholders in a way that generates discussions and understanding among team members, helping them to work together to turn requirements into working products and services. User stories are used to describe fragments of a product or service. The technique can be used differently.
Based on personas, the designer can gather data about customer journeys and needs and articulate corresponding requirements in small, unambiguous user stories. A user story has a very specific and simple form: the user may require something to enable a certain benefit. For example, a person may need a large car to take the family on holiday; someone else may need express car pickup at the airport to reach a meeting. A user story is easy to write, understand, prioritize, and check. Refinements and demos can help solve a problem with little investment.
Story mapping is done differently in diverse environments. A common way to map the requirements for a product or service is to describe the product or service as an epic, and then break the epic down into features and further down into user stories.9 This method is shown in Figure 5.3 and explained further in Table 5.9.
The first sprint delivers a minimum viable product (MVP) that is released to the users and used to co-create value and collect feedback before more stories are added to the product or service.
The INVEST acronym provides a useful reminder that user stories should be:
• independent
• negotiable
• valuable
• estimatable
• small
• testable.
Figure 5.3 An example of story mapping
Table 5.9 Using epics, features, enablers, and stories to articulate requirements
Type |
Description |
Example |
Epics |
An epic is an initiative delivering new products, services, or customer journeys to customers. The epic is the large story or a user story, which is too big to cover in one sprint. Epics are comprised of large collections of features. |
The entire user experience from hiring a car to delivering it. |
Features/enablers |
A feature is a collection of related user stories that represent a whole area of functionality or a capability that a product or service owner is interested in. A feature is realized by some number of user stories. An enabler is a technical prerequisite for a feature that supports exploration, architecture, infrastructure, or compliance. |
A busy manager can pick up the car at the airport to reach a meeting. |
User stories/enabler stories |
A piece of functionality described in a way that could be developed in a single sprint. As a <user> I want <requirement> so that <benefit>. |
A busy manager can order fast-track pickup at the airport to reduce stress. A busy manager can leave the airport without paying a parking fee to reduce waiting time. |
Story mapping is often used in combination with Agile service design methods, such as Scrum. In Scrum, the product owner is responsible for prioritizing the user stories in each sprint. At the end of the sprint, the product team will demonstrate the features for real users and gather feedback.
The MoSCoW method is a simple prioritization technique for managing requirements. It allows stakeholders to explicitly agree on the different priorities.
The method also covers the requirements that will not be delivered. This is useful, as lists are commonly overpopulated with unnecessary requirements, such as reports that nobody will need. These requirements increase cost without adding value.
The MoSCoW acronym stands for:
• Must The mandatory requirements covering the most important needs.
• Should The requirements that should be included if possible.
• Could The requirements that could be included if they do not affect the ‘should’ or ‘must’ requirements.
• Won’t Requirements that will not be included this time but may be included in a future release.
5.2.7 Weighted shortest job first
Sometimes requirements have matching priorities. In these cases, the MoSCoW method may be replaced by or combined with more granular techniques, such as bubble sorting. However, these approaches may not be feasible if stakeholders’ perspectives need to be aligned.
An alternative is to use the weighted shortest job first (WSJF) method (Reinertsen, 2009) adopted from the scheduling algorithms used in computer operating systems. In this method, the weight of a job is divided by the duration or size. The weight that is specifically recommended for product or service development is the cost of delay. Cost of delay is a measure that indicates value realization in terms of lost outcomes and retained uncertainty. In traditional service management terms, cost of delay can be considered a result of delay to service impact (service outcome), urgency (time criticality), and risk (uncertainty). Each job or requirement is scored and then prioritized according to its cost of delay divided by its duration (CD3). This method is illustrated in Figure 5.4.
Figure 5.4 Cost of delay divided by duration adapted to service management terms
5.3 Designing service offerings and user experience
Modern methods for software development have enabled a new generation of digital services. These methods have one important factor in common: they involve the customers and users throughout the design and implementation process of the products and services.
Value-driven and data-driven service design implies an iterative approach based on frequent feedback, continual experimentation, and learning to ensure value co-creation in each step of the design process. This requires engagement, involvement, and interaction between different roles by the service provider and the service consumer.
The service provider will bring its expertise on the development methods, but its success will depend on the customer engagement. The customer should be ready to provide its best-suited resources for the process and to ensure that they are empowered to make decisions on behalf of the organization.
It is important to note that agreements or contracts may restrict the possibility of Agile and flexible delivery models. When solving complex problems, agreements that allow for an Agile and flexible model are a prerequisite for the provider and the customer to be able to work in a constructive partnership.
Lean thinking can be described as a process improvement philosophy that prioritizes flow efficiency over resource efficiency. In Lean, flow refers to the way work progresses through a system. A work unit can be defined as a piece of work flowing through the value stream. A good flow means the work unit moves steadily and predictably, whereas a bad flow describes a system with a lot of queues where the work unit will have to stop and wait.
Table 5.10 The five Lean principles
Lean principle |
Explanation |
Identify customer value |
The first thing is to understand what the customer needs. What creates value for the customer? What is the desired outcome? Why is it needed? When and where is it needed? How much? How frequently? |
Map the value stream |
Next is understanding and mapping the value stream. From the moment a service provider receives a request from the customer for a new or changed product or service, the required activities need to be designed, built, transitioned, and delivered. The key is to define the work unit (request, product, service) and map how it flows through the value chain. Each flow represents a value stream. |
Create flow |
The work unit may be subject to several bottlenecks in the value stream. From the perspective of the work unit, this is waste. The flow is improved by eliminating waste. |
Establish pull |
When flow is created, the next step is to optimize the value stream. This ‘pull’ principle ensures that work is not pushed downstream. It allows batch size and work in progress to be limited, so that work units are finished in time. |
Seek perfection |
This principle reflects continual improvement. |
Lean defines five basic principles which are outlined in Table 5.10. Regarding stakeholder value, these principles focus on supporting an efficient and continuous flow of designing products and services.
Value stream mapping is a Lean technique for illustrating and analysing the logic of a value stream: a method of visualizing the flow from demand/opportunity to value, then planning how that flow can be improved. A value stream map gives a graphical overview of the flow of material and information and identifies areas for improvement. It is a good foundation for understanding how activities are connected and value is created.
A more detailed description of how Lean thinking is applied to service management can be found in ITIL ® 4: High-velocity IT.
5.3.2 Agile product and service development
Agile methods for software development started with the Agile Manifesto in 2001 with an encouragement to prioritize individuals and interactions over workflows and tools, working products over comprehensive documentation, customer collaboration over contracts, and responding to changes over following a plan.10
One aspect of the Agile philosophy is to apply Lean thinking. The work unit in an Agile development process is either a feature, which is a piece of limited functionality, or an enabler, which is a technical precondition for a functionality.
Another aspect is iterative development. In Scrum, requirements are captured in a backlog that is continually prioritized for the next sprint by a product owner. The development team will develop as much as they can in a sprint for a demonstration at the end of the sprint to capture feedback from real users. The method and the teamwork will be evaluated at a review meeting at the end of each sprint.
This approach helps the service provider and service consumer to grow together. They can start by defining a minimum viable product that works and realizes value from the beginning of their partnership and then they can expand on service utility, warranty, and experience as the parties mature together.
Continuous deployment is another aspect of the Agile philosophy. This means that features and enablers are continuously integrated, tested, and deployed so that they can be released as soon as the customer is ready to use them. This aspect requires close collaboration between the service provider and the customer, which means the customer must continuously be available for test and release. Some of the methods used for continuous deployment include:
• Feature flags An ‘on/off’ button programmed into the feature. When the customer is ready, the feature flag can be turned on. If something is wrong, the feature can be turned off again.
• Dark launch A new functionality is launched, but the link to the new functionality is not visible before the functionality is mature enough.
• Canary release A dark launch in which a few test users are invited to test the new functionality.
• A/B releases A technique used to test which of two alternative solutions is the best. It could be an alternative graphical design or functionality. The consumers are randomly split into two groups and test two different versions of the same feature.
These techniques make it possible and safe to develop and release new functionality quickly.
User-centred design is an iterative design process which holds the user at the centre of all design decisions throughout the project process. User-centred design ensures that the product and the service focus on what users need and on the user experience.
Service design thinking is an effective way of tackling problem-solving. Since the core of the method is to explore, prototype, and gather feedback from real users, it is a good example of value-driven, data-driven, and user-centred service design. It encourages users to define value and is a method that continuously gathers feedback on what is and is not working.
The ultimate objective of the service design thinking process is to identify solutions to the original challenge that are desirable, feasible, and viable.
Blueprints are architectural drawings of building designs. These blueprints depict what the building should look like and all the specifications required for the construction. For digital services, a blueprint is a diagram visualizing the service usage that aims to optimize the user experience.
In a service blueprint, the key elements are separated with three horizontal lines:
• The line of interaction This pinpoints the direct service interactions between the customer/user and the service provider.
• The line of visibility This separates the service activities that are visible to the customer and users from those that are not visible. Visible activities appear above this line and invisible activities appear below this line.
• The line of internal interaction This separates the employees in contact from those who do not directly support interactions with customers and users.
For one service, there may be multiple blueprints if there are several different scenarios. When drafting a blueprint, it is important to proceed from the top line and work down the template.
Figure 5.5 shows an example of a service blueprint.
Figure 5.5 Example of a service blueprint
Service blueprints are useful in order to:
• link the customer journey to products and services
• highlight user touchpoints and service interactions
• discover weaknesses and identify opportunities for optimization
• bridge cross-department efforts and avoid double workload.
In summary, service blueprints help organizations to understand how a service is implemented by a service provider and how it is used by the customers and users. A service blueprint pinpoints the dependencies between employee-facing and customer/user-facing processes. It also helps service providers to identify pain points, optimize complex interactions, and understand possibilities for improving the service design and customer journey and reducing costs.
Templates and more information on how to make service blueprints can be found in the business analysis practice guide.
5.3.6 Designing for onboarding
As part of a user-centred approach, the onboarding approach should be defined for every product, service, and service offering as part of the design to smooth onboarding.
A documented onboarding approach is used for planning an onboarding initiative. Onboarding approaches include scope, actions, stakeholders, timelines, and other aspects of onboarding. They may vary depending on the structure of service offerings, consumer resources, scale, legal and regulatory requirements, risks, and more.
One extreme is a narrow band of visibility, whereas an opposite extreme, such as a broad band of visibility, could be a comprehensive transition programme (including the transfer of employees and infrastructure), implementation of integrations between the involved organizations, establishment of a joint governance structure, and retirement of old products and services. Onboarding approaches should be carefully planned and tested during the service.
When defining the onboarding approach and planning onboarding initiatives, organizations should consider all four dimensions of service management. It should also be influenced by the external factors (ITIL Foundation, section 3.5).
One way to structure the onboarding approach is to follow the steps of the continual improvement model, as shown in Table 5.11.
Table 5.11 The continual improvement model and the onboarding approach
Continual improvement steps |
Onboarding approach |
What is the vision? |
Define the expected result of the onboarding |
Where are we now? |
Establish the baseline and determine the scope of the onboarding, including the required resources |
Where do we want to be? |
Define the onboarding goals, including the ideal combination and interaction of the resources |
How do we get there? |
Plan onboarding actions and responsibilities |
Take action |
Run the onboarding actions according to plan |
Did we get there? |
Control the onboarding and ensure its success: controls and metrics compared to baseline and goals |
How do we keep the momentum going? |
Review and improve |
When an onboarding approach is being designed as part of a product, service, or service offering, key activities include:
• identifying those provider’s resources that will interact with the consumer’s resources
• identifying those consumer’s resources that will interact with the provider’s resources
• identifying the need for introducing each pair of resources
• exploring opportunities to optimize and automate introductions
• creating procedures where manual or human-controlled introduction is required
• testing the procedures and updating them based on test results (repeat as needed)
• documenting and communicating to the involved parties.
The following ITIL practices support the design of products and services for smooth and effective user onboarding:
• architecture management
• service design
• service level management
• service validation and testing
• software development and management.
The ITIL story: Designing service offerings and user experience
|
Mariana: Our trailer rental has been successful with customers. Our next step is to iteratively build the automated booking process for trailers into Axle’s booking app. In our manual iteration, we discovered that it is useful to include pictures of the different trailer types, so that customers can identify which trailer will suit their requirements. |
|
Henri: We will do a canary release of the first iteration of the automated booking process for trailers, with just a few test users. Then we can roll it out to our customers and develop the features as we progress. |
5.4 Selling and obtaining service offerings
After the products, services, and service offerings have been designed, they need to be sold. This can happen before or after they are built, depending on the nature of the service and the service relationship. Both internal and external service providers need to sell their services. The sale activities will vary depending on whether customers are internal or external.
Pricing requires a decision about how much the customer will be charged. Many pricing options can be used to price a service, as shown in Table 5.12. For a service to be viable, it must generate enough income to cover investments and costs and generate profit, unless the service provider is a non-profit organization.
For commercial service providers, charging is tied less to the cost, and more to the value of the perceived service and relative costs of similar services provided by competitors. In these cases, the cost models will indicate the lowest level of charging before impacting profitability. Commercial service providers may also base their decision on the preferred pricing model or the expected value of the service sale and trends of consumption over the year.
Table 5.12 Pricing options
Pricing option |
Description |
When applicable |
Cost |
This option is based on a break-even or cost recovery model. The chargeable item is priced as close as possible to the actual cost of the cost units. |
For internal service providers or non-profit organizations. |
Cost plus |
The mark-up (%) can either be set by the service provider to match returns on other investments or allocated by the service provider to meet strategic business needs. |
The mark-up can be used for encouraging the use of new products and services while discouraging the use of legacy products and services. |
Market price/going rate |
The price is comparable with similar service offerings on the market. |
Commodity and out-of-the-box services. It is important to remember that sourcing services externally offsets some of the commercial risk from the customer to the service supplier. |
Fixed price |
The service provider sets a price based on negotiation with the customer, which covers a set period and a predicted consumption. |
Enables the parties to lock the price regardless of cost fluctuations, e.g. if a customer has a fixed budget. |
Differential charging |
Setting different charges for different usage of the same or similar services at different times. |
Enables an organization to reward some usage patterns over others, e.g. discouraging service usage during peak-time periods. |
Key message
Several factors should be considered when deciding the price of a service:
• How good is the service provider at communicating the value of the service?
• How much are the customers willing to pay?
• Are there similar services in the market?
• How are similar services priced?
• Is it easy to scale the service?
• Is it easy to onboard new customers?
• Could the service be used as a loss leader?
• How mature is the service provider?
• Can the triple bottom line approach influence the pricing?
In some cases, pricing can be used in the short term to undermine competition.
Raising awareness about available services is the first step of selling to internal customers. Internal sales and promotions, combined with incentives and pricing mechanisms, are important for managing demand.
Some benefits of selling to internal customers are:
• enhanced utilization of existing services
• better control of the service demand
• improved communication with customers and users
• feedback on how well services meet the needs.
Internal sales contribute to the overall customer perception of the internal service provider.
One of the most important tools for the internal sales process is the service catalogue: a communication tool for promoting services. For the service provider, it helps define and make products and services visible. The service catalogue is vital for relationship management, promoting existing services, and discovering the need for new services. It is also a key tool for service level management when defining service levels.
The most important thing for the service consumer is that the services are being used. The service desk has a key role to play in this, and will often make ordering forms and self-service systems available to the users, as well as providing the necessary guidance and assistance on how to use the products and services. Therefore, the service desk will always be a key contributor to the internal sales process and the user experience.
For more information, please refer to the following ITIL practices:
• relationship management
• service catalogue management
• service desk
• service level management
• service request management.
Additionally, most of the traditional techniques used for external sales can also be applied by the service provider.
External customer sales are more like traditional sales techniques, such as advertising and sales campaigns. The sales process depends on the type of service relationship, the nature of the parties, and contextual factors. These include the following:
• In highly regulated environments and in the public sector, acquiring goods and services may be subject to regulation; certain service providers may have been pre-authorized to sell their products and services.
• Some service consumers require that purchasing is done by a procurement team.
• Others may have defined formalized purchasing processes that include formal request methods, such as requests for information, requests for quotation, requests for proposal, proof of concept, demos, etc.
Table 5.13 shows the different methods for requesting products and services.
Table 5.13 Different methods for requesting products and services
Request for information |
Request for quotation |
Request for proposal |
Gathering information to identify potential vendors When you are looking for information Ask general questions Casual Fast |
Targeted request for pricing for a highly specific product or service When you know exactly what you need Ask questions about requirements Structured Focus on price |
Strategic and intensive proposal process When you want to compare proposals Ask specific questions Formal Comparison of vendors |
A successful sales process depends on good communication, trust, and fairness. The service provider should avoid creating a higher price for a service than it is worth for the customer. The service consumer should avoid pressuring for a price reduction that will cause the service provider to struggle to deliver.
A typical mistake is beginning a sale by promoting multiple products and services. Instead, the service provider should ask questions and listen. This way, the service provider will understand the needs of the customer before trying to fulfil them.
It is important that service consumers do not prepare lists of requirements based on experiences with outdated products before talking to potential service providers. Instead, they should describe requirements that are based on their actual needs, then listen to the service providers. The service providers may be able to offer new and better ways to fulfil specific needs based on their product and service portfolio and on previous experiences with other customers.
The ITIL story: Selling and obtaining service offerings
|
Mariana: We need to onboard the new trailer rental service, which means adding it to our service catalogue, educating our support staff about trailer availability, and managing the demand for trailers. Trailer rentals peak at the beginning and end of each term when students are most likely to move, but mid-term rentals do occur. |
5.5 Summary
To determine whether stakeholders may benefit from a mutual service relationship, the service consumer and the service provider need to build a business case, shape and match their demand and supply, and articulate their needs and opportunities in the form of requirements and service offerings. Products and services can only be designed when the service consumer’s needs are truly understood.