Deliver and support

Most of the time, most people experience a service through the deliver and support activity. It is where services are actually provided day after day: systems run, requests are fulfilled, questions are answered and incidents are resolved. If design and transition and obtain/build create the service, deliver and support keeps it working for consumers. This lesson examines the purpose, inputs and outputs of deliver and support, how it handles different types of work, how it measures performance and how it feeds improvement back into the system.

The purpose of deliver and support

In plain terms, deliver and support ensures that services are delivered and supported according to agreed specifications and stakeholder expectations. Agreed specifications include service level agreements, operational level agreements and contracts. Stakeholder expectations go further: users expect services that are easy to use and quick to restore even where no formal agreement says so. Deliver and support must meet both.

The activity covers routine service operation (running systems, monitoring, backups, capacity management), user support (answering questions, fulfilling requests, resolving incidents) and the collection of information about how services are performing. It draws on practices such as service desk, incident management, service request management, monitoring and event management, problem management, and infrastructure and platform management.

Inputs and outputs

Deliver and support receives new and changed products and services from design and transition, service components from obtain/build, user support tasks from engage, improvement initiatives and plans from improve, and knowledge and information about new and changed services and components. Its outputs include services delivered to customers and users, information on the completion of user support tasks for engage, product and service performance information for engage and improve, improvement opportunities for improve, contract and agreement requirements for engage, and change requests for obtain/build.

Types of work in deliver and support

Deliver and support handles several types of work, each with different characteristics. Standard requests are predictable and can often be automated. Incidents are unplanned and urgent. Operational tasks are scheduled and routine. Problems require investigation over time. Recognizing which type of work is which helps the organization route it correctly and set suitable expectations.

Restoring service quickly

When an incident occurs, the priority is to restore service, not to find the root cause immediately. Root cause analysis belongs to problem management and can happen later. Deliver and support measures how quickly service is restored using metrics such as mean time to restore service (MTTR) and the share of incidents resolved within target times.

Shift-left and self-service

Many organizations aim to resolve work as early and as close to the user as possible. This approach is often called shift-left. Instead of every question going to specialist teams, the service desk resolves more on first contact, and users resolve more themselves through self-service and knowledge articles. Shift-left reduces cost and wait times, provided the knowledge and tools are good enough.

Little's Law in support queues

Deliver and support teams manage queues: tickets waiting to be worked on. Little's Law, from queueing theory, links three quantities in a stable system: the average number of items in the system (L) equals the average arrival rate (λ) multiplied by the average time each item spends in the system (W).

Little's Law is useful because it shows that, for a given arrival rate, the only way to reduce waiting time is to reduce the number of items waiting, and vice versa. A team with a large backlog will have long waits unless it increases throughput or reduces arrivals.

Measuring deliver and support

Deliver and support produces much of the performance information the organization uses. Useful measures combine outputs (volumes, response times) with outcomes (user satisfaction, business impact avoided). ITIL-110 warned about watermelon reporting, where service level agreements look green while users are unhappy. Good measurement in deliver and support includes the user's perspective as well as the provider's.

Feeding improvement

Deliver and support is the activity closest to how services actually behave, so it is the richest source of improvement opportunities. Recurring incidents, frequent requests that could be automated, gaps in knowledge articles and supplier performance problems all surface here. A mature organization makes it easy for support staff to raise improvement ideas and makes sure those ideas reach the improve activity and the continual improvement register.

Deliver and support and the other activities

Deliver and support depends on every other activity. It needs well-designed, well-tested services from design and transition; reliable components from obtain/build; clear expectations from engage; priorities and capacity from plan; and improvements from improve. When deliver and support struggles, the cause often lies upstream: a poorly designed service, a missing runbook, an unreliable supplier. The value chain view encourages looking for those causes rather than blaming the support team.

US organizations that support services handling personal information face state breach notification laws, which every state has enacted, and sector rules such as HIPAA for health data. Deliver and support teams need procedures that connect incident handling to these obligations.

Deliver and support in ITIL (Version 5)

The lifecycle activities reported for Version 5 split this territory into operate, deliver and support. Operate covers keeping systems and services running; deliver covers providing the service to consumers; support covers helping users and restoring service. Published course outlines also mention concepts such as reliability and observability under the value chain. The skills in this lesson apply in either edition.

Knowledge as a support asset

Much of the performance of deliver and support depends on knowledge: articles that explain how to fix common problems, runbooks for operational tasks and records of past incidents. Knowledge that is accurate, findable and up to date lets the service desk resolve more on first contact and lets users help themselves. Knowledge that is outdated or scattered across personal notes does the opposite. Many teams adopt a simple rule: whenever an agent resolves something not covered by an existing article, they create or update one before closing the ticket.