ITIL Experience (Version 5) – knowing how people “live” technology and what needs to improve
Ivo Umlenski – Cloud Availability Manager, IBM, and beta tester for ITIL Experience
What is the importance of technology "experience"?
A system can be operational and still deliver an unacceptable experience — slow, confusing, anxiety-inducing; essentially, a service can be technically functioning and still fail the person using it.
In my Cloud Availability Management role – constantly at the intersection of infrastructure reliability and human perception – experience is everything, though it's often invisible until something goes wrong. For example, if a cloud service flickers for 30 seconds and the user loses trust, that erodes engagement, even if our SLAs show 99.9%.
While availability management is traditionally measured in numbers, such as uptime percentages, mean time to repair, and SLA compliance, the new ITIL Experience module reframes what "available" actually means: positive experiences build trust and loyalty; negative ones create distance and disengagement, and experience shapes outcomes far beyond satisfaction scores.
It shapes how people feel about the services we manage, the teams that deliver them and, ultimately, the organization itself.
Experience is not a layer on top of availability management. It is availability management, seen through human eyes.
ITIL Experience – putting human experience at the core of technology
ITIL Experience (Version 5) helps organizations treat experience not as a "soft" add-on, but as a core discipline — one that sits alongside all the familiar ITIL practices, including availability management.
The module explicitly connects availability to experience domains: it recognizes that service disruptions, downtime events, and even how people communicate those events are all experience moments.
This adds a new maturity to previous ITIL versions, acknowledging that what the user feels during an incident — the emotional, cognitive, and even bodily response to uncertainty — is as real and consequential as the incident ticket itself. And managing this well can ensure better trust and adoption of technology.
For an availability manager, this is validating. It means our work must go beyond instrumentation and SLAs to how people anticipate, perceive, and evaluate the reliability of our cloud services.
Core concepts in practice
The module introduces a powerful iterative loop, and it resonates deeply with how effective availability work functions at its best:
Noticing: this is more than just observing but being attentive and receptive to signals — both digitized (usage patterns, escalation trends, chatbot transcripts) and non-digitized (hesitation in calls, workarounds, silence where feedback is expected). In my context, that might mean noticing that users are logging tickets not because of an outage but because the service feels uncertain — and that feeling is a signal worth acting on.
Interpreting: this requires treating every signal as a hypothesis, not a settled truth. The module warns against false certainty and observer bias. For cloud availability, this means interpreting patterns in context and across multiple tiers of evidence.
Hypothesizing: this formalizes the idea that metrics are also proxies. KPIs rest on an assumption. The module's "hypothesis chain" concept — connecting actual state to target state through a series of hypotheses — is directly applicable to availability improvement: If we improve mean time to restore by X%, we hypothesize that user-perceived disruption drops by Y%.
Experimenting: this means running the smallest safe change and measuring it precisely. This brings rigor and humility to improvement — no big-bang transformations, just testable, bounded interventions with clear owners and rollback plans (followed by “Learn” and “Adjust”).
Together, these four activities replace gut-feel improvement with structured, human-centered, evidence-informed iteration.
An approach that is equally practical and honest
Of all the practical tools in the module, the one with the most genuine power to change how teams work is the Continual Experience Improvement cycle.
Not because it is the most elaborate, but because it is the most honest. It acknowledges something most improvement frameworks quietly avoid: that experience is never finished, never solved, never optimized once. It is alive — shifting with people, context, and the accumulating weight of every interaction that came before.
What distinguishes the cycle above all is Step 0. Before formal improvement even begins, it asks teams to do something powerful: notice. Not analyze, not prioritize, not build a business case — simply surface the signals of friction, frustration, and quiet disengagement before they harden into something more damaging.
In cloud availability, this reframes our entire starting point. Step 0 asks us to also respond to what is felt but not yet filed — the client who has stopped escalating, not because things are better, but because they have stopped expecting better. That silence is a signal.
From there, the cycle moves teams through naming a human vision for a moment, assessing where they honestly are, agreeing on what good looks like across roles, and then acting — always with proportionality and humility. Every change is a hypothesis. Every intervention is the smallest, safest one. Every cycle ends not with a conclusion but with a question: what do we notice now?
The return to noticing is what makes this a genuine cycle rather than a linear process. It creates what the module calls ‘a living rhythm of attending, acting, and adapting’ that becomes part of how a team works, not an interruption to it.
For my team, embedding this cycle would shift something fundamental: from responding to what goes wrong toward continuously attending to what it feels like to depend on us. That is a different kind of accountability — and, ultimately, one more worthy of the trust our clients place in us every time they rely on a service we are responsible for.
Managing the role of AI in improving experience
The ITIL Experience module refuses to treat AI as either a panacea or a threat. Instead, it offers something more useful: a language for being precise about what AI is doing, and a framework for governing it with integrity.
The ITIL AI Capability Model — the 6Cs: Creation, Curation, Clarification, Cognition, Communication, and Coordination — gives teams a way to name exactly which function an AI system is performing. This matters because different functions carry different risks, require different human oversight, and create different experience implications.
For cloud availability, the most human-experience-relevant capabilities are Cognition — AI detecting patterns, predicting disruptions, identifying bottlenecks before they become failures — and Communication, where AI personalizes incident updates to match a user's language, role, and context.
Done well, this is deeply humanizing: instead of a generic broadcast during an outage, a user receives an acknowledgment that actually speaks to their situation. Done poorly, it creates the experience of an automated response.
The module is explicit about the governance this requires: decision boundaries, human handoff rules, documented AI Capability Model cards, and a commitment to remaining human-centric throughout. AI delivers value only when people use it with confidence. That sentence should be on the wall of every operations team deploying automation into client-facing services.
Experience improvement – calling out what’s not working
The case made by the module – which I find both practical and quietly radical – is that experience improvement depends on people feeling safe enough to name what isn't working.
This is not just about clients submitting formal complaints, but engineers noticing hesitation in a handoff, support agents carrying the emotional weight of client frustration, and team members spotting workarounds that have quietly become standard practice. These are signals. They are real work. And they go unheard in cultures that only trust dashboards.
So, for my team, this means building the conditions — the psychological safety, the shared vocabulary, the role clarity — that allow those signals to surface and be acted on. It means empowering the people closest to the client experience to make small, proportionate judgments without waiting for distant approval. It means being honest that emotional labor — the effort of calming an anxious client during an incident, of absorbing frustration while explaining a delay — is skilled, valuable work that should be recognized and supported.
For my organization, the ITIL Experience module offers something that has long been missing: a common language that connects infrastructure teams, product owners, client experience functions, and leadership around a shared question — what does this moment feel like for the person living it, and how do we make it better?
That question, asked consistently and with genuine curiosity, is where lasting improvement begins.