The Evolution of IT Service Management

From Mainframe Operations to AI-Driven Enterprise Services

For IT Leaders and Technology Decision-Makers

Executive Summary

IT Service Management has spent fifty years trying to answer one deceptively simple question: how do you reliably deliver technology services to people who depend on them? The answers have changed dramatically with each passing decade - shaped by the scale of computing, the ambitions of the organisations using it, and the maturity of the professionals responsible for keeping the lights on.

This article traces that journey. It covers the informal operations centres of the 1960s mainframe era, the government-commissioned frameworks of the 1980s, the commoditisation of ITSM tooling through SaaS in the 2000s, the expansion into Enterprise Service Management, and the current wave of AI capability that is changing what is even possible. 

1. The Mainframe Era: Operations Without a Framework (1960s–1970s)

Computing in the 1960s was physically enormous and organisationally narrow. IBM, Burroughs, and a handful of others supplied mainframe systems to governments, universities, and large corporations. These machines lived in climate-controlled rooms, tended by specialist operators who understood them in the way a ship's engineer understands an engine room - through proximity, experience, and a healthy respect for what happens when something goes wrong.

There was no IT Service Management in any formal sense. When a system failed, engineers investigated, fixed what they could find, and restarted. If the fix required the manufacturer's involvement, someone picked up the phone. Batch jobs were scheduled on paper. Priorities were set by whoever had the most institutional authority in the room. The idea that computing resources existed to *serve* end users had not yet been articulated.

This is worth understanding, because the reactive culture of those early operations centres never fully went away. It persisted into the help desk era, into the first generation of ITSM tools, and it remains visible today in organisations that have adopted modern platforms without changing how they think about service.

The First Help Desks

The mid-1970s brought computing to a wider audience. Minicomputers from DEC and HP made it possible for organisations to put terminals on desks outside the data centre. Non-technical staff were suddenly operating systems they had received minimal training on. They needed help, and they needed it from someone.

The help desk emerged from this gap. In its earliest form it was nothing more than a dedicated phone line staffed by a technically competent person who fielded calls, diagnosed problems verbally, and either resolved them on the spot or escalated to someone who could. There were no ticketing systems. No knowledge bases. No metrics. Resolution quality depended entirely on who answered. When experienced staff left, their knowledge left with them.

The structural problems were obvious. Costs were invisible because there was no mechanism to measure them. Recurring problems were solved repeatedly because there was no record of previous solutions. Users had no reliable expectation of when their problem would be addressed. The help desk was, in practice, organised chaos with a phone number.

2. ITIL and the Age of Frameworks (1980s–1990s)

The CCTA Commission

By the early 1980s the British government was spending heavily on information technology and getting inconsistent results across departments. Different agencies had developed entirely different approaches to running their systems. Some were methodical, others chaotic. Almost none of them shared knowledge with each other. The Central Computer and Telecommunications Agency (CCTA) was tasked with doing something about it.

The CCTA's response, developed over the second half of the 1980s, became the IT Infrastructure Library — ITIL. The first version was published between 1989 and 1995 as a collection of books covering specific aspects of IT operations. Problem Management, Configuration Management, Change Management, Service Desk, each volume described best practices drawn from organisations that were doing things well. The intention was to give government departments a common vocabulary and a set of proven approaches they could adopt rather than invent from scratch.

ITIL v1 was imperfect. It was dense, difficult to navigate, and written with a degree of bureaucratic caution that made it cumbersome to apply in practice. The library ran to more than thirty volumes at its peak. Critics pointed out that following it slavishly could produce an organisation that was very good at managing processes and very slow at doing anything useful.

The criticism was fair. But ITIL v1 established something that had not previously existed: a shared language for IT service delivery. Terms like incident, problem, change, and configuration item gave practitioners a common framework for discussion. Organisations could compare approaches. Consultants could carry knowledge from one engagement to the next. The discipline of IT service management, as a distinct professional field, began to coalesce.

ITIL v2 and Global Adoption

The CCTA consolidated and revised the library through the late 1990s, culminating in ITIL v2. Published around 2000, v2 reduced the sprawl considerably and organised the content around two core publications: Service Support and Service Delivery. These covered the day-to-day operational processes (Incident Management, Problem Management, Change Management, Release Management, Configuration Management) and the longer-term service planning processes respectively.

ITIL v2 landed at the right moment. Organisations across the world were grappling with the aftermath of Y2K remediation, the fallout from dot-com investments that hadn't paid off, and increasing board-level scrutiny of IT spending. CIOs needed a way to demonstrate that IT was being managed professionally. ITIL provided the vocabulary and the structure to do that.

Adoption spread rapidly through the UK public sector, then into Europe, then Asia-Pacific and North America. The ISEB in the UK and EXIN in the Netherlands began certifying practitioners. ITIL Foundation certification became a standard line on IT CVs. A cottage industry of consultants, trainers, and tool vendors grew up around the framework.

By the mid-2000s, ITIL was the closest thing the industry had to a universal standard for IT service delivery.

Contemporaneous Frameworks

ITIL was never the only game in town, though it was the most widely adopted. The IT Service Management Forum (itSMF) was founded in 1991 and provided a community for practitioners to share experience outside the formal framework. Microsoft published its own Microsoft Operations Framework (MOF) in 1999, designed to apply ITIL principles specifically to Microsoft environments. COBIT, developed by ISACA, addressed IT governance from a control and audit perspective rather than a service management one. ISO/IEC 20000, first published in 2005, gave organisations a certifiable standard for IT service management that aligned closely with ITIL but carried the weight of international standardisation.

These frameworks coexisted with varying degrees of tension. Consultants often argued about which one was most appropriate for which context. In practice, most large organisations ended up using elements of several, fitting them together pragmatically rather than following any single framework to the letter.

3. The First Generation of ITSM Tools (1990s–Early 2000s)

Moving Beyond Spreadsheets

For much of the 1990s, the tooling available to ITSM practitioners was inadequate for the frameworks they were trying to implement. Help desk software existed (Remedy launched its Action Request System in 1991) but configuring it to match ITIL processes was typically a significant project in its own right. Many organisations tracked incidents in spreadsheets, problems in email threads, and change requests in paper forms.

Remedy became the dominant enterprise help desk platform through the 1990s. It was powerful and flexible, capable of representing complex ITIL processes, and it was correspondingly expensive and difficult to implement. A Remedy deployment was a major undertaking, often requiring specialist consultants and months of configuration work. Smaller organisations simply couldn't afford it.

Other vendors entered the space. Peregrine Systems, Axios Systems, CA Technologies (formerly Computer Associates), and HP all offered ITSM platforms of varying sophistication. The market fragmented along predictable lines: large enterprises bought Remedy or the HP product, mid-market organisations chose from a growing list of alternatives, and smaller organisations made do with generic helpdesk applications or continued using email.

The Configuration Management Database Problem

ITIL v2's Configuration Management process introduced the concept of the Configuration Management Database - a central repository recording all IT assets (configuration items) and the relationships between them. In theory, a well-maintained CMDB would give IT teams a definitive picture of the IT environment: what existed, how components related to each other, and what services they collectively supported.

In practice, the CMDB became one of ITSM's most persistent failure modes. Populating it accurately required discovery tools, disciplined processes for recording changes, and sustained organisational commitment. Most organisations underestimated the effort involved. CMDBs were built with enormous investment, fell out of date almost immediately, and ended up being neither trusted nor used for anything critical. The gap between the CMDB in theory and the CMDB in practice was a source of considerable frustration in the industry.

4. ITIL v3, Service Strategy, and the Lifecycle Model (2007)

ITIL v3, published in 2007, represented a significant philosophical shift. Where v2 had focused primarily on operational processes, v3 attempted to situate those processes within a broader service lifecycle: Service Strategy, Service Design, Service Transition, Service Operation, and Continual Service Improvement. The ambition was to connect day-to-day IT operations to longer-term business strategy.

The reception was mixed. Practitioners who had built careers on v2 found v3 abstract and difficult to apply. The Service Strategy volume in particular attracted criticism for being academically oriented in a way that was hard to connect to the realities of running a service desk. The examination structure became more complex, and the number of specialist certifications multiplied.

What v3 got right was the insistence that IT service management needed to engage with business outcomes rather than simply optimising internal processes. An IT department that could demonstrate flawless Change Management processes but couldn't articulate the business value of the services it delivered was, in v3's view, missing the point. That argument was correct, even if the framework around it was unwieldy.

ITIL 4, published in 2019, continued in this direction, introducing the Service Value System, replacing the lifecycle with a more flexible value chain model, and explicitly acknowledging the influence of Agile, DevOps, and Lean thinking. It was a more practically grounded document than its predecessor, and its adoption has been steady if unspectacular.

5. The SaaS Revolution and the Rise of ServiceNow (2000s–2010s)

Cloud Changes the Economics

The emergence of Software as a Service as a viable delivery model through the mid-2000s altered the economics of ITSM tooling fundamentally. The barrier to adopting a capable platform dropped sharply. Organisations no longer needed to budget for on-premises infrastructure, lengthy implementation projects, or specialist DBAs to keep the system running. A subscription-based SaaS platform could be live in weeks rather than months.

ServiceNow was founded in 2004 by Fred Luddy, a former CTO of Peregrine Systems. Luddy's insight was that enterprise software had become unnecessarily complex and that a platform built for the cloud from the ground up could deliver sophisticated ITSM capability at a fraction of the traditional cost. Early ServiceNow was modest by current standards with a clean, workflow-driven ticketing platform with solid ITIL process coverage, but it worked reliably and was straightforward to configure.

ServiceNow's growth through the late 2000s and into the 2010s was striking. The platform attracted customers who were frustrated with the complexity of Remedy and similar on-premises tools, and it used their feedback aggressively to extend its capability. By the time it IPO'd in 2012, ServiceNow was already the dominant force in cloud-based ITSM. Its revenue growth consistently outpaced the market.

The Competitive Response

Remedy's owner, at that point BMC Software, was slow to respond to the SaaS threat. Its Helix platform eventually arrived as a cloud offering, but it carried the architectural weight of a product that had been built for a different era. HP's ITSM portfolio went through a series of rebrands and restructurings that undermined customer confidence. CA Technologies' product remained strong in certain verticals but never achieved broad market dominance.

A second tier of SaaS-native ITSM vendors established themselves during this period. Freshservice, launched in 2010, targeted the mid-market with a genuinely accessible interface and competitive pricing. Jira Service Management (formerly Jira Service Desk) gained traction in organisations where development teams were already using Jira for project tracking, offering a natural integration between development workflows and service management processes. ManageEngine's ServiceDesk Plus continued to serve organisations that needed capable tooling without enterprise pricing.

The overall effect was a dramatic improvement in the quality of tooling available to the full market, not just to large enterprises. A company with two hundred employees could now implement a credible ITSM platform that would have been financially out of reach a decade earlier.

6. DevOps, Agile, and the Tensions with Traditional ITSM (2010s)

The 2010s introduced a significant fault line into the ITSM world. DevOps (the set of practices aimed at integrating software development and IT operations) spread rapidly through technology organisations, particularly those building and running their own software products. Its core proposition was that the separation between developers (who built things) and operations teams (who ran them) was a source of slowness, friction, and failure. Breaking down that separation, through shared tooling, shared responsibility, and automated deployment pipelines, produced faster, more reliable software delivery.

Traditional ITSM and DevOps made uncomfortable neighbours. ITIL's Change Management process, as typically implemented, required formal approval for any change to a production environment. In organisations following a standard Change Advisory Board process, this meant weekly meetings, multi-week lead times, and documentation requirements that made sense when changes were infrequent and consequential, but became absurd when a mature DevOps team was deploying dozens of times per day.

The conflict was real and it played out visibly in organisations trying to do both. DevOps teams regarded the CAB as a bureaucratic obstacle; ITSM practitioners regarded DevOps releases as ungoverned risk. Both positions had merit. The resolution, where it was reached, came through adapting the Change Management process to distinguish between standard changes (pre-approved, low risk, automated), normal changes (requiring assessment and approval), and emergency changes (often getting retroactive approval and documentation). Pre-approving the pipeline itself rather than each individual deployment became the practical answer for high-velocity teams.

ITIL 4 formally acknowledged this tension and positioned itself as compatible with Agile and DevOps. Whether it succeeded in convincing practitioners who had already dismissed ITIL as irrelevant to modern development practice is a different question.

7. Enterprise Service Management: Beyond IT (2015–Present)

The Logic of Expansion

By the mid-2010s, a pattern was becoming visible in organisations that had mature ITSM implementations. The processes and tooling that IT had built for managing incidents, requests, changes, and knowledge were useful beyond IT. HR departments were managing employee requests through email and phone calls in exactly the way IT departments had before they built service desks. Facilities teams were tracking maintenance requests on spreadsheets. Legal departments were fielding contract queries through shared inboxes.

The gap between how IT managed services and how the rest of the organisation managed services was striking. IT had decades of accumulated practice, mature frameworks, and capable tooling. Everyone else was largely improvising.

Enterprise Service Management (ESM) is the application of ITSM principles and platforms to non-IT business functions. The term covers a spectrum of activity, from simply extending an existing ITSM tool to manage HR ticket intake at one end, to fundamentally redesigning how an organisation delivers shared services across all business units at the other.

HR, Facilities, Legal, and Beyond

The HR function has been the most common starting point for ESM adoption. The parallels with IT service management are direct: employees make requests (onboarding, offboarding, policy queries, payroll issues), HR processes those requests, resolves them, and closes them. An ITSM platform can represent that workflow with minimal adaptation. The benefit is immediate — requests are tracked, response times are measurable, common questions are answered through a knowledge base rather than through individual consultations, and the HR team has visibility of their workload in a way they previously lacked.

Facilities management has been a close second. Buildings need maintenance, equipment needs repair, space needs to be allocated. These are service requests and incidents in exactly the same sense as IT service requests and incidents. The process overlay is essentially identical.

Legal, procurement, and finance have followed, though with more variation in how readily they adopt the model. Functions that deal in sensitive information or complex judgment have been appropriately cautious about reducing their work to tickets, and the challenge of capturing tacit professional knowledge in a knowledge base is genuinely harder in those domains.

The Platform Consolidation Effect

ESM has driven a significant platform consolidation trend. An organisation that uses ServiceNow for IT, Workday for HR, a facilities management system, and a contract management tool for legal is running four separate workflow engines, four separate data models, and four separate user interfaces. The business case for consolidating on a single platform - or at least creating a unified front-end through a shared service portal — is clear when laid out this way.

ServiceNow pursued this opportunity aggressively, building out dedicated modules for HR (HRSD), Customer Service Management, Legal, and others. Salesforce positioned its Service Cloud similarly. The ambition, in both cases, was to become the operating platform for the entire organisation's service delivery, not merely the IT department's ticket system.

Whether the full vision of a single enterprise service platform is achievable, or desirable, remains a live debate. Integration complexity, data governance requirements, and the deep process specificity of individual business functions all create friction. Consolidation often progresses further in aspiration than in practice.

8. AI Enters ITSM: From Chatbots to Intelligent Operations (2017–2023)

The First Wave: Virtual Agents and Chatbots

The first AI capability to reach mainstream ITSM adoption was the virtual agent — a chatbot interface allowing users to log incidents, check request status, or find knowledge base articles through a conversational interaction rather than navigating a form-based portal.

The early implementations were, in most cases, underwhelming. Rule-based systems masquerading as intelligent agents, they worked adequately for narrow, well-defined queries and failed noticeably when users deviated from expected patterns. Users quickly learned which questions the bot could handle and which required a human agent, and many of them went straight to the human agent rather than waste time on the bot.

The underlying problem was that first-generation virtual agents were decision trees, not intelligent systems. They couldn't understand intent, couldn't handle ambiguity, and couldn't learn from their mistakes. The marketing positioned them as AI; the technology was closer to an elaborate phone menu.

AIOps: Making Sense of Operational Data

A more substantive early application of machine learning in ITSM was in the area that came to be called AIOps - the application of AI to IT operations data. Modern IT environments generate extraordinary volumes of telemetry: logs, metrics, events, alerts from monitoring systems across infrastructure, applications, and networks. The volume is too large for human operators to process manually. Alert fatigue - the state in which operations teams have so many alerts that they can no longer meaningfully prioritise them - had become a genuine operational risk.

AIOps platforms applied machine learning to this data to identify patterns, correlate related events, distinguish genuine incidents from noise, and in some cases predict failures before they occurred. Platforms from Moogsoft, BigPanda, and later integrated capabilities from Splunk, Dynatrace, and others demonstrated that ML could meaningfully reduce the alert noise reaching human operators and accelerate root cause identification.

The results were real, though context-dependent. Organisations with large, complex environments and mature monitoring practices got the most value. Those with incomplete or inconsistent monitoring data found that the AI amplified their existing problems rather than compensating for them - a reminder that data quality is a precondition of AI effectiveness, not something AI can substitute for.

Predictive and Prescriptive Capabilities

Machine learning also began to appear in more targeted ITSM applications through this period. Predictive assignment — routing incidents to the agent most likely to resolve them based on historical data — reduced resolution times in organisations with large, specialised support teams. Similar incident detection — automatically identifying when a new incident matched the pattern of a known problem — reduced duplicate diagnostic effort. Predictive change risk scoring gave Change Managers a data-informed basis for assessing which changes were likely to cause problems.

None of these were transformative individually. Collectively, they began to change the shape of a well-run ITSM function: less time spent on triage and routing, more focus on resolution and prevention.

9. Generative AI and the Current Landscape (2023–Present)

The ChatGPT Effect on ITSM

The public release of ChatGPT in late 2022 and the subsequent explosion of interest in large language models changed the conversation in ITSM, as it changed conversations in almost every industry. The capabilities that LLMs demonstrated - natural language understanding, coherent generation of text, the ability to synthesise and summarise information across a range of topics - were directly applicable to the problems ITSM practitioners had been trying to solve for years.

The virtual agent problem, which had never been convincingly solved by rule-based systems, was a natural fit. An LLM-powered virtual agent can understand intent from a user's natural language description of a problem, ask relevant clarifying questions, search a knowledge base for relevant articles, draft a resolution response, and escalate with a summary if it cannot resolve the issue. The gap between this and the decision-tree chatbots of the preceding decade is substantial.

ServiceNow, Freshservice, Jira Service Management, and every other significant ITSM vendor integrated generative AI capability into their platforms through 2023 and 2024, under product names including Now Assist, Freddy AI, and Atlassian Intelligence. The pace of feature release has been rapid enough that the platforms available today are materially different from those available eighteen months ago.

Knowledge Management Transformed

One of the most significant practical impacts of generative AI in ITSM has been on knowledge management. Creating and maintaining a useful knowledge base has always been difficult. Writing a clear, accurate knowledge article requires time and skill that frontline support agents rarely have in abundance. Articles go out of date and nobody notices until a user follows the instructions and finds they no longer work. Search meant that users often couldn't find the article they needed even when it existed.

LLMs address several of these problems at once. They can draft knowledge articles from resolved incident records, substantially reducing the effort required to capture resolution knowledge. They can identify knowledge gaps by analysing patterns in unresolved queries. They can improve search through semantic understanding rather than keyword matching. Organisations that have deployed these capabilities in production report meaningful reductions in the time required to produce and maintain their knowledge bases.

Autonomous Agents and the Shift Toward Self-Healing IT

The frontier in ITSM AI as of 2026 is the autonomous agent - a system that can not only diagnose a problem and recommend a solution, but take remediation action autonomously within defined boundaries. Restart a service. Provision additional compute capacity. Roll back a failed deployment. Patch a known vulnerability. These capabilities exist in various forms across the leading platforms, though the degree of autonomy that organisations are comfortable delegating to AI agents varies considerably.

The caution is understandable. An autonomous agent with poorly defined boundaries can make things significantly worse, at a speed that human oversight cannot match. The practical approach that most organisations have taken is graduated autonomy - clearly defined categories of action the agent can take without approval, tighter categories requiring confirmation, and hard stops for anything with significant blast radius.

The longer-term trajectory points toward something that was entirely theoretical when the CCTA began work on ITIL: an IT environment capable of detecting many of its own problems, resolving the straightforward ones automatically, escalating the complex ones with context already assembled, and continuously learning from the outcomes. The human service desk doesn't disappear in this model — but its character changes substantially, shifting from first-line triage toward exception handling, relationship management, and the oversight of AI-driven processes.

10. Where the Industry Stands and What Comes Next

The State of ITSM in 2026

The ITSM market is large, mature, and moving quickly. IDC and Gartner estimates put the global market at well over fifteen billion dollars and growing at high single-digit rates annually. ServiceNow occupies a dominant position at the enterprise end, with Jira Service Management and Freshservice competing vigorously in the mid-market. A long tail of specialist and regional vendors serves specific industries and use cases.

The frameworks have evolved to reflect the modern environment. ITIL 4 is widely taught and certified against, though practitioners are more selective in what they apply than in the framework-obsessed early 2000s. VeriSM, the DevOps Institute's body of knowledge, and the SIAM (Service Integration and Management) framework address aspects of service management that ITIL does not fully cover.

Outsourcing and managed services remain significant. Many organisations, particularly those without the scale to justify deep in-house ITSM expertise, contract service delivery to managed service providers. The quality of managed ITSM has improved substantially as tooling and practice have matured, though the customer-provider relationship introduces its own governance complexity.

The Problems That Remain Stubborn

Fifty years of accumulated practice has not solved everything. The CMDB accuracy problem persists in many organisations — the gap between what the configuration management database says exists and what actually exists in the environment remains a source of chronic operational risk. Service desk attrition rates remain high; the role has historically been positioned as entry-level, and career progression into more senior IT roles, while possible, is not always visible to the people doing the work. Knowledge management remains harder to sustain than to initiate; the initial energy around a knowledge base project rarely survives the first annual review.

The relationship between ITSM and security operations has also been unresolved for longer than it should have been. Incident management in ITSM and incident response in security share vocabulary but have historically operated from separate platforms with limited integration. The convergence of these disciplines is overdue and is slowly happening, driven partly by regulatory pressure and partly by the practical difficulties of managing a security incident through two disconnected process frameworks simultaneously.

The Road Ahead

The direction of travel is reasonably clear. AI capability in ITSM will continue to advance, and the ceiling on what can be automated will rise. The platforms will absorb more of the enterprise service delivery surface, extending ESM into functions that have not yet been modernised. Observability data and service management data will increasingly be managed as a unified operational intelligence layer rather than in separate silos.

The underlying challenge does not go away as the tools improve. It just takes different forms. The organisations that will manage technology most effectively in the next decade are, in all probability, the ones doing the hardest thinking now about governance, data quality, and what role they want humans to play in a service model that is being substantially reshaped by AI.

The help desk that started with a phone line and a technically capable person has come a very long way. It is still changing.

Key Milestones at a Glance

About this article

This article was prepared as an independent overview of ITSM history and current market conditions. It does not represent the position of any vendor, framework body, or certification organisation. References to vendors are illustrative of market developments and do not constitute endorsement.