ITSM Was Management.
What Comes Next Is Evolution.

Seventy percent of organizational change efforts fail (McKinsey, 2019), and ITSM implementations are no exception. Not because the frameworks are wrong, but because the word is wrong.

For thirty years, this industry has organized itself around “management.” Manage the incidents, manage the changes, manage the services. And the word shaped the culture. Some teams broke through and built something better, but most stayed stuck because the operating model never gave them room to improve. The result? Eighty-one percent of organizations still view it as a cost center (Gartner, via Serviceware, 2026). That’s not a technology problem. It’s a language problem.

The people doing the work feel it. Seventy-four percent of IT support staff report negative well-being, up from sixty-one percent just two years ago (HDI, via InvGate, 2026). The same tickets, the same workarounds, the same incidents coming back month after month. You can’t manage your way out of a cycle like that. Management maintains, but it doesn’t transform.

ITIL 4 saw this. The Service Value System was a genuine attempt to move past the old thinking, from lifecycle stages to value streams, from process compliance to co-creation. The instinct was right, but the language never fully shifted. Practitioners still say “service management.” The industry still calls itself ITSM. The conferences, the certifications, the job titles all stayed anchored to a word that pulls people back into a defensive posture. I don’t think the framework is the barrier. The mindset is.

Service Evolution isn’t a rebrand; it’s a different operating premise. Management spent thirty years asking one question: how do we control this? Service Evolution asks a different one: how does this get better every cycle? One reacts to failure, and the other treats failure as data and feeds it back into the system.

AI makes this possible in a way it wasn’t five years ago. Not AI as a chatbot bolted onto your service desk, but AI as the mechanism that lets an operation learn from every incident, every change, and every interaction. Pattern recognition across thousands of tickets, proactive identification of problems before users feel them, and platforms that can predict capacity issues days before they impact users (Dynatrace, 2026). The technology exists, but what’s missing is the mental model that puts it to work.

The frameworks aren't broken. The word we built them around is.

Good Ideas We Could Never Execute

ITSM had good ideas. Genuinely good ones. Event correlation, dynamic SLAs, proactive problem management weren’t bad concepts; they were impossible assignments. We asked humans to carry out meticulous, process-heavy procedures designed to fix human oversight, error, and forgetfulness. The solution to “people make mistakes” was “people, please follow this 47-step procedure perfectly every single time.” That was never going to work.

Take event correlation. The idea has been around for years: connect the signals across your monitoring tools, your service desk, and your infrastructure to find the pattern before the outage finds you. Beautiful in theory, but a midsize operation can generate over 5,000 alerts a day (Splunk, 2026). No human team on earth can correlate that volume in real time, so we triaged what we could and hoped the rest was noise.

We had the data. Oh, did we have the data. Dashboards full of it, reports nobody read, and the problem was never collection — it was comprehension. The whole culture optimized for activity, not productivity: tickets closed, SLAs met, green on the board, but nothing actually got better. We just measured motion and called it progress. Slicing and dicing those metrics at the speed decisions actually require was beyond what any analyst could sustain. You’d finish last month’s trend analysis just in time for it to be irrelevant.

Dynamic SLAs and experience-level agreements sounded revolutionary: make targets respond to real conditions in real time, adjust based on actual customer experience. But “dynamic” requires reaction speed humans don’t have. By the time you spotted the breach, the customer had already felt it.

Then there's problem management, the practice everyone admires and almost nobody does well. The cycles required to get from a recurring incident to an actual root cause were so labor-intensive that most organizations looked at the effort and asked the only honest question: is the juice worth the squeeze? And the answer, almost everywhere, was no, so they skipped it. They resolved the same incidents over and over and called it operational maturity. Research backs this up: only 48% of organizations implement structured improvement cycles from their incidents (PagerDuty, 2026), and 30–50% of service desk tickets are repetitive, resolvable issues that keep coming back (Quinnox, 2026). We knew the repeat work was killing us, but we couldn’t stop the bleeding fast enough.

And then there was the big one: the dreaded major incident. A config change goes sideways at 2 AM on a Friday, and by Saturday morning you've got twenty people on a bridge call, half of them still figuring out what they're looking at. Someone asks, "What depends on this service?" and the room goes quiet because the CMDB that was supposed to answer that question tracked assets and config items, not dependencies. There’s a principle from Michael Cardinal, an ITSM thought leader and frequent contributor to ITSM Academy's monthly webinar series, that has stuck with me ever since: don't invest in tools before you've defined the rules. And that's exactly what happened. Organizations spent millions on configuration management databases before they ever defined how dependency data would be captured, maintained, or used, then wondered why nobody trusted the CMDB on the bridge calls where it mattered most. The CMDB was designed to map dependencies, but most implementations never maintained that data. It told you what you had, but it couldn’t tell you how things connected. That data point about 13% of ticket types driving 80% of lost productivity (HappySignals, via InvGate, 2026)? A lot of that traces back to the same dependency blindness repeating across every major incident.

These were never management failures. They were computing problems that we kept throwing people at. The speed, depth, and precision required to actually execute these practices — to correlate thousands of events, to make SLAs genuinely dynamic, to trace root causes across dependent services — exceeded what human cognition could deliver. Not because the people were bad at their jobs, but because the jobs were inhuman.

AI doesn't fix this because it's magic. It fixes this because pattern recognition at scale, real-time correlation, and dependency mapping are exactly what machine intelligence does. Five thousand alerts compressed to a hundred actionable items and root cause suggestions that used to take weeks surfacing in minutes. These were always computing problems. We just didn’t have the right compute.

Why I Almost Left This Industry

I need to be honest about something. I almost walked away from ITSM entirely.

When ITIL 4 was released, I was energized. For those of us in the industry, it was real forward momentum, a modern take on ITIL v3 that had been the standard since 2011. The guiding principles, the Service Value System, the shift from rigid processes to flexible practices. The ideas were genuinely good. I earned my ITIL 4 Trainer capabilities, taught classes, and built consulting engagements around the new material. And parts of ITIL 4 did help. It gave me a better way to approach engagements, applying the right practice, in the right place, at the right time, without forcing a one-size-fits-all framework onto teams that couldn't absorb it.

But the material itself had problems. The diagrams confused more than they clarified, particularly around the SVS and the service value chain. Real-world applications like value stream mapping should have been far more prominent. The ITIL Practitioner material, which was genuinely useful, was minimized and distilled down when it was rolled into ITIL 4, losing ideas that practitioners actually needed. In 2018, it was what the industry was capable of releasing at the time, but it wasn't the guiding material it should have been. The adoption surveys reflect that: only 20% of organizations actively adopted it (ITSM.tools, 2026). The ideas were sound, but the packaging wasn’t.

I’ll be honest about something else. I started one of the ITIL 4 advanced exams and never finished the journey. Not because I couldn’t, but because I’d lost the passion to invest deep thinking into certifications when I could see the real world had already moved past what the tests were measuring. There was a disconnect — and it turned me off.

The industry didn't move with it either. The ideas never excited the execs, owners, or practitioners the same way they energized me. It was still too heavy and too complicated for the people who needed it most. And without me being there to provide constant care and feeding, the process improvements I helped build were eventually lost. The iterative approaches, the new ways of working, the value stream thinking — teams would adopt it, show progress, and then slide back the moment the next fire hit the queue.

It was still humans doing human tasks to fix human error. Attempt after attempt.

Executives were largely reticent to have the conversation about what their teams need to do to call themselves successful. Directors and managers were open to process improvement, but they felt the pressure: vast numbers of high-priority tickets, non-cross-functional teams, vocal customers demanding answers now. Technicians looked at ITIL 4 as another course they would need to carve out time to fulfill.

I exhausted myself trying to make it stick.

I stepped back. Left LinkedIn for several years, dialed back consulting, and reassessed my path forward. I needed to figure out whether the problem was the industry, the framework, or me.

Then I started going deep on AI. Not the vendor pitch version, the real thing. I built apps, learned how large language models work, launched microbusinesses powered by tools I built myself, and rewired how I think about problems. That’s when it hit me: AI can fix almost all of the problems I'd been throwing people at for twenty years.

Not by replacing people, but by handling the computational work that was never a human job in the first place: the pattern recognition, the correlation, the measurement, the repetitive triage. The work that exhausted every team I'd ever consulted for.

Vendors appear focused on dropping AI in to bolster this add-on or that feature. But nobody I’ve found was tackling this from an ITSM practice perspective — not the tooling, the practice itself.

When ITIL 5 was released, the AI coverage landed primarily on governance: risk management, ethical adoption, and regulatory compliance. Governance, by its nature, tells you the rules and regulations, what to watch out for, not what to do with it. It doesn’t tell a six-person IT team how to use AI to stop the same incidents from coming back every month. The industry needed an execution playbook and it got a guardrail. Both are necessary, but only one was delivered.

I've spent the last year and a half using AI to build, learn, and rethink what's possible. I don't have a portfolio of enterprise AI implementations to point to. What I have is a practitioner's conviction — built from twenty years of watching the same problems resist every framework we threw at them — that AI changes the equation. These are my ideas on where the industry should focus. Service Evolution is the starting point, not the finished product. And I'd rather put the idea out there and let the community sharpen it than wait until I have all the answers.

Instead of admitting defeat, I re-energized. I rebuilt my company, came back to LinkedIn, launched meetups across six Florida cities, and started writing.

I'm back. This is the line in the sand.

This is Service Evolution. And it starts here.

Defining Service Evolution

Every ITSM framework started from the same assumption: services need to be managed, controlled, governed, and documented into compliance. And for most of that history, the assumption was correct, because the only tool we had for detection, correlation, and pattern recognition was a person staring at a dashboard.

That constraint is gone. AI handles computational work at a speed and scale that no team ever could. Which means the operating question isn't "how do we manage this?" anymore.

It's "how does this get better every cycle?"

That shift needs a name. We're calling it Service Evolution.

Service Evolution is the practice of continually advancing IT operations where AI handles the computational work and humans handle the judgment work. AI does the detection, correlation, and pattern recognition. People do the deciding, the prioritizing, and the relationship-building.

It’s not a framework and you won’t find a certification for it. There’s no maturity model with five levels and a consulting engagement at each one. Service Evolution is a discipline you practice and build into the way your team operates, not something you buy from a vendor.

At Tideline Insights, we're introducing the term because the industry needs language for what should be happening in IT operations. Teams that stop trying to control every variable and start building systems that improve themselves. There hasn’t been a word for that, and now there is.

"Service evolution" as a concept has been discussed in customer experience circles for years. This isn't that. This is a specific operating model for IT where AI absorbs the management layer and practitioners focus on advancing services. We’re not describing a journey; we’re naming a discipline.

And no — this isn't AIOps with a new name. AIOps is a technology layer, the tooling that does the pattern recognition and correlation. Service Evolution is an operating discipline that includes AIOps but also includes people, purpose, and practice. You can buy AIOps, but you can’t buy a discipline. You have to build it.

Three Markers of an Evolved Operation

What would an operation look like if it made this shift?

It would be adaptive. Ticket volume spikes on Monday mornings and routing rules have already shifted before the queue backs up. A new application throws unfamiliar error patterns and detection adjusts without someone filing a change request. The operation responds to conditions instead of waiting for a human to notice them.

It would be predictive. Not crystal-ball predictions, more like “your storage consumption trend hits capacity in 11 weeks and here are the three services affected” or “this service has had four near-miss availability incidents in the last 30 days and the pattern correlates with a specific change window.” The kind of foresight that used to live inside one senior engineer’s head would live in the system.

And it would be insightful. Not just telling leadership what happened, but surfacing which services generate revenue, which ones drain it, and where the next investment should go. The kind of portfolio and strategy intelligence that ITIL 4 envisioned in its Strategy Management and Portfolio Management practices, but that most organizations never had the data quality or processing speed to deliver. That’s when IT stops being a cost center and starts being a business partner.

Where Service Evolution Meets ITIL 5

Nobody's saying the word "management" becomes wrong. Processes still need governance, changes still need approval logic, and incidents still need coordination. That work doesn’t vanish.

But AI absorbs the mechanical parts: the detection, the triage, the correlation, the measurement, the reporting. What’s left is the judgment, the strategy, the relationships, and the hard calls. That’s evolution, and that’s what your team was always supposed to be doing.

That’s not a slogan; it’s an operating model. And it starts the next time your team sits down and asks what got better this week and what they’re going to make better next.

What This Means for You

If You're a CIO or VP of IT

You already know 81% of IT departments are still viewed as cost centers (Gartner, via Serviceware, 2026). You feel it every budget cycle, defending headcount instead of presenting strategy. Service Evolution changes what you bring to the table. When AI handles the computational layer, you show up with clean before-and-after data on what IT actually delivered. Not uptime percentages. Reduced downtime, faster resolution, lower cost per interaction, and direct alignment between IT improvements and business outcomes your customers actually feel. The conversation shifts from “why does IT cost so much?” to “what else can IT improve?”

If You're an IT Director or Manager

You’re the layer where transformation lives or dies, and you’re exhausted. Manager engagement hit 27% in 2025 (Gallup), the lowest of any role in the organization. You’re expected to lead change you were never equipped for, with tools that generate more noise than signal. Here’s what changes: Service Evolution gives you a rhythm. Weekly check-ins surface what’s broken, monthly reviews measure whether fixes worked, and quarterly presentations prove it to leadership. Each round, the operation gets measurably sharper. You stop firefighting and start building something that compounds.

If You're a Service Desk Lead or Technician

The service desk is the single point of contact between IT and everyone it serves (ITIL 4). That means the people sitting there absorb the full weight of every frustration, every outage, every “this should have been fixed already.” Thirty-five to forty tickets a day, 66% of service teams reporting burnout (Customer Contact MindXchange, 2025), and most of the work is repetitive: password resets, access requests, the same issues cycling back week after week. What if AI absorbed that repetitive layer — not to replace the people, but to give them room to operate with empathy? Room to listen instead of rush. Room to spot the pattern behind the fifth ticket about the same issue and actually do something about it. Seventy-one percent of Gen Z would take a pay cut for meaningful work (McKinsey, 2024). Service Evolution doesn’t cut the service desk; it gives the people on it the freedom to improve the delivery instead of just surviving the chaos.

If You're an MSP Owner

Your clients are already asking about AI. Over half of US businesses now expect their MSP to have adopted it (Digitalisation World, 2026). Your margins are shrinking and competing on response time is a race to the bottom. ITIL 4’s Service Level Management practice warned about the “watermelon effect”: SLAs that look green on the outside while the client is unhappy underneath. You’ve seen that QBR. Service Evolution flips the model. Instead of selling hours and green dashboards, you sell measurably improved operations that clients can feel, cycle over cycle. The MSP that evolves its clients’ services faster than competitors takes the market, and that gap is there for anyone willing to move first.

If You're an ITIL Practitioner or Consultant

You’ve spent years mastering frameworks. You see a new term and think “here we go again, another rebrand,” and that’s fair. But Service Evolution isn’t replacing ITIL; it amplifies and initiates it. Without practitioners who understand incident management, change enablement, and continual improvement, AI is just fast automation of bad processes. Your expertise becomes the foundation everything else depends on. You’re not threatened by this shift. You’re the reason it works.

Where to Start: Monday Morning

You don’t need a new certification or permission from a vendor. You need a starting point.

Outcomes over outputs. That's the line that separates what IT has been doing from what IT should be doing. ITSM measured tickets closed, SLAs met, and dashboards green, while Service Evolution measures problems that never come back, value the business can actually feel, and teams that are measurably better this quarter than last.

Coming in This Series

The next three articles in this series give you the machinery.

The Evolution Cycle builds the rhythm — weekly, monthly, quarterly — that makes improvement automatic instead of aspirational. Seek & Solve is the mechanism: predict, prevent, solve, learn. And The 30-Day Proof is exactly what it sounds like, the playbook for proving this works before anyone has to believe you.

The industry spent thirty years optimizing a machine it failed to aim. Service Evolution aims it. Teams that compound instead of just maintaining, and an operation that learns instead of just running.

But none of that matters until you answer six words:

Sources

• McKinsey & Company. (2019). The irrational side of change management. McKinsey Quarterly.
• Gartner, via Serviceware. (2026). From Cost Center to Value Driver. Serviceware SE.
• HDI, via InvGate. (2026). ITSM Statistics, Facts, and Insights for 2026. InvGate Blog.
• ITSM.tools. (2026). ITIL 4 Adoption Levels: The News Will Surprise Many.
• Splunk. (2026). AIOps Explained: Detection, Prediction, and Mitigation in IT Operations. Splunk Blog.
• PagerDuty. (2026). 2026 State of AI-First Operations Report.
• Quinnox. (2026). AI in ITSM: 12+ Use Cases Transforming IT Service Management.
• HappySignals, via InvGate. (2026). ITSM Statistics, Facts, and Insights for 2026. InvGate Blog.
• Dynatrace. (2026). Dynatrace Advances AIOps with Preventive Operations. Dynatrace Press Release.
• Michael Cardinal, ITSM thought leader, frequent contributor to ITSM Academy's monthly webinar series. Principle paraphrased from practitioner discussions.
• Gallup. (2025). State of the Global Workplace Report.
• Customer Contact MindXchange. (2025). Breaking the Burnout Cycle in Customer Service Teams.
• McKinsey & Company. (2024). Gen Z workplace preferences survey.
• Digitalisation World. (2026). How MSPs Can Embrace AI to Build Competitive Advantage in 2026.

Ryan Holzer is an ITIL Expert and the founder of Tideline Insights, an ITSM consultancy built on practical frameworks, emerging technology, and trusted advice. He runs free ITSM meetups across Florida for IT leaders, directors, and their teams. Find one near you at floridaitsm.com. Follow the Service Evolution series at serviceevolution.ai.