The service value chain and its six activities

At the heart of the service value system sits the service value chain: an operating model that describes the key activities an organization needs to respond to demand and turn it into value. ITIL 4 names six activities: plan; improve; engage; design and transition; obtain/build; and deliver and support. This lesson introduces all six, explains how they connect through inputs and outputs, and shows why the chain is a network of activities rather than a production line. Lessons 4 to 7 then examine the activities in depth.

What an operating model is

An operating model describes how an organization does its work: which activities happen, how they connect and what flows between them. It sits between strategy (what the organization wants to achieve) and day-to-day execution (who does what, with which tools). The value chain is ITIL's generic operating model for creating, delivering and continually improving services. It is generic on purpose. Every service organization performs these activities in some form, but each configures them differently.

The word chain can mislead. In manufacturing, a value chain often implies a linear sequence: raw materials in, finished goods out. The ITIL service value chain is better pictured as a set of interconnected activities, each of which can trigger, feed or receive from any other. A piece of work might pass through engage, then design and transition, then back to engage, then obtain/build, then deliver and support, with improve touching all of them.

The six activities at a glance

The descriptions below are written in plain language. They capture the purpose of each activity without reproducing official wording.

Inputs and outputs

Each activity receives inputs and produces outputs. Some inputs come from outside the organization (demand from consumers, components from suppliers). Others come from other value chain activities. For example, deliver and support produces information about how services are performing; that information is an input to improve and to plan. Engage produces requirements; those are inputs to design and transition. Obtain/build produces service components; those are inputs to deliver and support.

Thinking in inputs and outputs makes dependencies visible. If design and transition is waiting for requirements, the problem may lie in engage, not in design. If deliver and support keeps receiving poorly tested components, the problem may lie in obtain/build or in design and transition. Mapping the flows lets the organization find the real constraint rather than blaming the team where the symptom appears.

Engage as the interface

Engage has a special position. It is the main point at which the value chain interacts with stakeholders outside it: customers, users, suppliers, partners and other parts of the organization. Demand typically enters through engage, and the value created leaves through engage when products and services are handed to consumers and feedback is gathered. That does not mean every conversation with a stakeholder happens in one team; it means the activity of understanding and communicating with stakeholders is recognized as essential and deliberately managed.

Value streams use the chain

Because the activities are generic, they do not describe how a particular piece of work flows. That is the job of value streams: specific combinations of activities, in a specific order, used to handle a specific type of demand. Restoring a failed service follows one value stream; onboarding a new employee follows another; developing a new product follows a third. Each uses some or all of the six activities, possibly more than once. Lessons 8 and 9 cover value streams in detail.

In tables and diagrams, arrows are used to show the order in which a particular value stream uses activities. The chain itself has no fixed order.

Practices support the activities

Activities describe what has to happen; practices supply the resources to make it happen. ITIL 4 describes 34 practices, grouped as general management, service management and technical management practices. Every activity draws on several practices, and every practice contributes to several activities. Incident management, for example, contributes most to deliver and support but also to engage (communicating with users) and improve (identifying improvement opportunities). ITIL-140 and ITIL-141 examine the practices; here the point is the many-to-many relationship.

The ITIL (Version 5) lifecycle view

ITIL (Version 5), released in February 2026, keeps the value chain and adds a product and service lifecycle. Published Version 5 course outlines, checked in October 2026, list eight lifecycle activities: discover, design, acquire, build, transition, operate, deliver and support. They describe the activities as iterative and non-linear, much as the value chain activities are. The lifecycle gives a finer-grained view of how a product or service comes into being and is run, while the value chain remains the operating model at the center of the value system.

Two cautions apply. First, this correspondence is our own study aid, not an official crosswalk, and some activities overlap. Second, exam questions should always be answered in the terms of the edition you are sitting. A Version 4 question about the six activities expects the six names exactly; a Version 5 question about the lifecycle expects the eight.

Activities versus departments

A frequent mistake is to map each activity to a department: a planning office, an engagement team, a design team, a build team, an operations team. That recreates the silos the system model was designed to remove. In practice, a single product team might perform engage, design and transition, obtain/build and deliver and support for its own product, while a central function performs plan and coordinates improve. Another organization might outsource obtain/build entirely to a partner. The value chain describes what must happen, not who must do it.

Why six activities are enough

Six activities may seem too few to describe everything a service organization does. The answer is that they are deliberately broad. Within each, many practices, procedures and tasks operate. The benefit of keeping the list short is that it provides a common language across very different organizations and makes it easier to see the whole. When a conversation stalls on whose process is broken, asking which activity is failing to produce the output another activity needs often unlocks it.