Ask a technician what they look after and they'll name systems: the email server, the network, the laptops. Ask the people they support what IT provides and you'll hear something completely different: "I can work from home," "invoices go out," "my email works." Neither answer is wrong — but the gap between them is exactly where IT departments go to be misunderstood, and closing that gap is the founding idea of ITIL.
The service lens
ITIL's core definition, stripped of committee prose: a service is a way of delivering value to someone without them having to own the cost and risk of the machinery behind it. The payroll team gets "everyone is paid correctly, monthly" — they don't own database licensing, backup strategy, or patching risk. That's the deal. IT owns the machinery; users receive outcomes.
This immediately explains behaviour that puzzles new technicians. Why does the business not care that the migration was technically brilliant? Because they experience outcomes, not effort. Why does a "minor" printer fault get executive attention while a major server upgrade gets none? Because one blocks an outcome someone needs today, and the other is invisible machinery. Users are not being ungrateful — they're being customers.
Outputs vs outcomes — the distinction that pays your salary
ITIL leans hard on this pair, and it's worth internalising: an output is the thing produced (a restored server, a configured laptop, a closed ticket). An outcome is what it enables (the analyst can present to the client at 2pm). Outputs are IT's view; outcomes are the customer's. The classic failure is delivering the output while missing the outcome — the laptop was reimaged perfectly, but a day after the presentation. Ticket closed; value zero. When ITIL documents talk about "focusing on value," this is the concrete meaning: keep sight of the outcome behind every output.
ITIL 4's fancy phrase for the deal between IT and its users is value co-creation — value isn't manufactured by IT and shipped like a parcel; it emerges when both sides do their part. Email service delivers no value until people use it well; a security service co-creates value only if users actually report the phishing. The point sounds philosophical but has teeth: it's why user training, adoption, and communication are legitimate parts of delivering a service — not extras bolted on after the technical work.
Try the lens on your own environment
A genuinely useful exercise, whether you're studying or already working: list five systems you (or your team) touch, then translate each into the service it exists for and the outcome that service enables. "Exchange server" becomes "people can communicate reliably from anywhere." Do this and you'll notice something: priorities become obvious. The system with the scariest technology isn't necessarily attached to the most important outcome — and now you're thinking the way service management thinks. Everything else in ITIL builds on this one lens.