PeopleCert Community
Groups
/
ITIL
/
navigation.content

ITIL, AI and Service Request Management

ITIL, AI and Service Request Management
# ITIL
# Service Management

Building the Catalogue That Fixes Your Service Desk

June 11, 2026
Robert Edward  Pinnington
Robert Edward Pinnington
ITIL, AI and Service Request Management

ITIL, AI and Service Request Management: Building the Catalogue That Fixes Your Service Desk

The role is not disappearing. It is being fundamentally rewritten.

There is a familiar conversation happening in ITSM circles right now. AI will automate the service desk. Chatbots will replace the analyst. The Service Request Manager is yesterday's job title. It is a seductive argument, but I have heard it before — whether it was the introduction of the internet or the arrival of desktop computers. It is almost entirely wrong. But only if you know what ITIL (Version 5) is telling us.
ITIL (Version 5) is not a cosmetic refresh. It is a deliberate and substantive evolution, built for an era in which AI is no longer a peripheral tool but a governed participant in the digital product and service lifecycle. It introduces the concept of Digital Products and Digital Experience, which add to the Digital Services that are already in our Service Request Catalogue.
For the Service Request Manager, this creates not redundancy but urgency: the role must evolve, and ITIL (Version 5) gives it both the architecture and the capability model to do so.
ďťż

The Problem Hiding in Plain Sight

Ask any Service Desk Manager where their team loses the most time, and the answer is almost always the same: requests that should never have been raised as incidents. A password reset logged as a service outage. A new starter equipment order routed to the incident queue. A software access request sitting in a priority-two backlog whilst an actual outage waits behind it.
This is not a people problem. It is a structural one — and it is costing organisations real capacity at the exact moment AI is offering a credible way to fix it.
The root cause is almost always the same: the organisation lacks a mature, well-structured service catalogue. Without clear, accessible request fulfilment pathways, users default to the channels they know — whether they be the incident form, an email or a call to the Service Desk. The result is a service desk that is simultaneously overwhelmed and under-utilised, handling high volumes of low-complexity requests whilst genuine incidents queue for attention.
ďťż

The Framework Has Changed — So Must the Role

ITIL (Version 5) makes this problem structurally visible through its Digital Product and Service Management (DPSM) lifecycle — an eight-component model that covers the full end-to-end journey of every digital product and service the organisation manages:
  • Discover — explore and prioritise needs and opportunities for the product and service.
  • Design — create product and service solutions meeting or exceeding requirements
  • Acquire — procure or allocate the resources required to build the product.
  • Build — create, configure, and test the technology solutions constituting the product.
  • Transition — deploy the new product into the live environment.
  • Operate — operate the product to ensure the agreed performance.
  • Deliver — deliver digital services based on the live products.
  • Support — restore normal operation of products and delivery of services when needed
For the Service Request Manager, this is consequential. Service requests are no longer transactional touchpoints sitting within an incident management silo. They help the Service Request Manager build digital products into digital services — giving clarity to the components of the offer. They are data-rich moments in an ongoing service journey: signals about product usability, experience quality, and value realisation.
A well-governed service catalogue is the operational expression of the Deliver and Support stages of this lifecycle. Every service item in the catalogue represents a capability that has been discovered, designed, built, and transitioned. Every fulfilment workflow is an Operate and Deliver activity. Every request that arrives misdirected as an incident is a failure of the Support stage to provide users with the right access point.
Under ITIL (Version 5)'s strengthened Value System — which aligns guiding principles, governance, value chain activities, management practices, and continual improvement into a coherent whole — those signals feed directly back into how services are designed and delivered. The Service Request Manager who understands this is not managing tickets. They are managing intelligence.
ďťż

AI as the Catalogue Architect

Rather than building a service catalogue from scratch through workshops, surveys, and educated guesswork, organisations now have a better starting point: their own historical data.
AI applied to incident and request records can do what manual analysis rarely has the time or consistency to do well. It can identify patterns across thousands of records — flagging the categories of tickets that recur at high volume, carry low technical complexity, follow predictable resolution paths, and share characteristics that clearly distinguish them from genuine incidents. In short: it identifies the misdirected requests, classifies them, and gives the Service Request Manager the raw material for a structured service catalogue grounded in actual user behaviour rather than assumptions.
The output is a catalogue built on evidence. Each service item maps to a real demand pattern. Fulfilment workflows are designed around how requests actually arrive, not how the organisation imagined they would. Self-service options target the highest-volume, lowest-complexity items — precisely those that currently clog the incident queue.
This is not AI replacing the Service Request Manager. It is AI doing the analytical heavy lifting so that the Service Request Manager can make informed governance decisions. The distinction matters.
ďťż

The 6C Model: The Service Request Manager's Governance Toolkit

This is where ITIL (Version 5)'s AI Capability Model — the 6C Model — becomes the Service Request Manager's most practical instrument. It does not describe what AI does in the abstract. It defines precisely how the Service Request Manager uses AI, within the ITIL Value System, to create, curate, clarify, cognate, communicate, and coordinate the service catalogue and the fulfilment of every request within it.
Creation — The Service Request Manager uses AI to generate net-new outputs: drafting service catalogue entries from structured data, producing fulfilment workflows from defined business rules, generating SLA documentation, and creating change announcements when catalogue items are updated. What previously required weeks of workshop output can be produced in hours, with the Service Request Manager governing the quality and accuracy of what is generated.
Curation — The catalogue is only valuable if it stays accurate. The Service Request Manager uses AI to continuously improve the quality, organisation, and relevance of catalogue content: detecting duplicate or obsolete service items, identifying inconsistencies between service descriptions and supporting supplier agreements, and flagging catalogue entries that no longer reflect how services are actually delivered. Curation is the discipline that keeps the catalogue trustworthy.
Clarification — The Service Request Manager uses AI to ensure users can find, understand, and navigate the catalogue with ease. AI summarises complex service descriptions into plain language, rephrases technical fulfilment instructions for non-technical audiences, and generates context-specific summaries for management reporting. This is what drives self-service adoption: not the existence of a catalogue, but users being able to use it without needing to raise an incident to find out how.
Cognition — This is the analytical engine that makes the whole approach possible. The Service Request Manager uses AI to identify patterns, anomalies, and insights across historical incident and request data: detecting recurring misdirected requests, surfacing bottlenecks in fulfilment workflows, forecasting demand spikes, and identifying emerging service needs that belong in the catalogue but are not yet there. As one ITIL Master has observed, where governance, practices, and continual improvement are well established, AI strengthens value co-creation. Where they are weak, AI accelerates instability. Cognition, properly governed, is the difference.
Communication — The Service Request Manager uses AI as the communicative interface between users and the catalogue. Virtual agents handle request submission. Chatbots provide guided self-service. Automated notifications keep users informed throughout fulfilment. Personalised major incident communications adapt to the user's role, language, and context. All of this happens without consuming service desk capacity — which is the point. The service desk is freed to manage incidents because communication around service requests is handled within a governed, AI-enabled framework.
Coordination — Finally, the Service Request Manager uses AI to execute and orchestrate fulfilment across systems and teams. Incoming requests are triaged and routed to the correct fulfilment path. High-impact exceptions are escalated automatically based on real-time analysis. Remediation workflows are triggered when defined thresholds are breached. Coordination is where the catalogue stops being a document and becomes an operational system.
ďťż

Governing the AI-Enabled Catalogue

ITIL (Version 5) is unambiguous: automated systems operating within the service environment require the same governance rigour as any other production component. For the Service Request Manager, this means several non-negotiable obligations.
Updates to AI models — changes to training data, decision logic, or routing thresholds — must follow the same change enablement process as any other production system change. An AI model that silently reclassifies a category of requests is a change event, whether or not it looks like one. Documented approval, risk assessment, and tracking are not optional.
Knowledge management provides the transparency layer. How the AI classifies requests, what data it was trained on, what its known failure modes are, and how exceptions are handled must be documented. This is the accountability foundation that makes the catalogue trustworthy — and defensible when something goes wrong, as it will.
Performance measurement must go beyond efficiency. A self-service catalogue that deflects sixty per cent of requests but generates user frustration, repeated contacts, or workaround incidents is not a governance success, whatever the cost savings look like on a dashboard. ITIL (Version 5)'s emphasis on user, customer, and employee experience gives the Service Request Manager a clear mandate to measure outcomes, not just volumes.
The DPSM lifecycle provides the governance frame for that measurement. Performance in the Operate and Deliver stages should be tracked against the service items the catalogue was designed to fulfil. Recurring failures in the Support stage — users still raising incidents for catalogued services — are a signal that the Discover or Design stages need revisiting. The lifecycle is a continuous feedback loop, and the data generated by an AI-governed catalogue feeds directly back into it.
ďťż

The Linchpin, Not the Casualty

The Service Request Manager who positions themselves within this model — using the ITIL Value System to govern the catalogue, and the 6C Model to deploy AI across every stage of service request management — is not a candidate for redundancy. They are a linchpin.
They are the professional who uses Creation to build catalogue content at scale, Curation to keep it accurate, Clarification to make it usable, Cognition to surface what belongs in it, Communication to connect users to it, and Coordination to deliver on the promise it makes.
ITIL (Version 5) does not automate governance. It requires it. The service desk gets its focus back — on incidents — because the Service Request Manager, properly equipped, has finally built the structure that makes that possible.
That is not a technology story. It is a governance story. And the Service Request Manager is the one who tells it.
Enjoyed this post? Join the conversation by leaving a comment or sharing your thoughts below, we’d love to hear your experiences and perspectives. Don’t forget to explore our upcoming events for more opportunities to learn and connect, and visit the forum to continue the discussion.
Sign in or Join the community
Where conversation, connection, and real-world practices come together.
PeopleCert Community
Create an account
Where conversation, connection, and real-world practices come together.
Comments (0)
Popular
avatar
ďťż
Dive in

Related

Blog
Reframing ITIL: From Service Management to Value Management
By Mike Alstrom • Nov 3rd, 2025 • Views 156
Blog
Beyond IT Service Management: ITIL as a Strategic Enabler of Data Governance and Management
By Yurguen Penaranda Th... • Jun 16th, 2026 • Views 9
Blog
AI Governance in Service Management
By Gabriel Espinosa • May 12th, 2026 • Views 72
Blog
Reframing ITIL: From Service Management to Value Management
By Mike Alstrom • Nov 3rd, 2025 • Views 156
Blog
Beyond IT Service Management: ITIL as a Strategic Enabler of Data Governance and Management
By Yurguen Penaranda Th... • Jun 16th, 2026 • Views 9
Blog
AI Governance in Service Management
By Gabriel Espinosa • May 12th, 2026 • Views 72
Terms of Service
Your Privacy Choices