A request would come in. Someone would read it. Someone would key it into another system. Someone would approve it, route it, fulfil it, and close it. Each step was a human moving information from one place to another. We had built sophisticated processes to manage that work, but we had rarely stopped to ask whether the work needed to be done by people at all.

That gap is the reason the Service Automation Framework exists.

ITSM gave us a powerful vocabulary for managing services. We learned to think in terms of incidents, requests, changes, and service levels. But the underlying assumption was almost always that a human sat at the centre of delivery. The frameworks optimised the workflow around that person rather than questioning whether the workflow could run on its own.

Meanwhile, the world outside the IT department had moved on. People had become comfortable searching, comparing, buying, and resolving issues entirely by themselves, online, at any hour. We had become a self-service generation in our personal lives, while the services delivered to us at work still depended on someone manually picking up a ticket.

Where most services still sit

Where the Service Automation Framework starts

Before concluding that something new was needed, we looked closely at what already existed. We evaluated ITIL, COBIT, and a number of other established frameworks to see whether automation was already addressed somewhere and we had simply missed it.

What we found was consistent. These frameworks are genuinely valuable, and each does its job well.

• ITIL describes how to manage IT services across their lifecycle.
• COBIT provides governance and control over IT.
• Others cover quality, security, or project delivery.

But none of them treats automation itself as the subject. Automation tended to appear as an afterthought, a technique you might apply within a process, rather than as a discipline with its own design principles, its own building blocks, and its own way of thinking about the user.

So in 2016 we set out to fill that gap, and the Service Automation Framework was co-created.

The goal was deliberately practical. We did not want to replace ITIL or COBIT, and the framework does not try to. We wanted a structured, methodical way to talk about service automation: a model that helps you decide which services are good candidates, how to design them around the user rather than around the existing process, and how to deliver and improve them over time.

The framework builds on ideas that ITSM practitioners already recognise: the notion of a service as a means of delivering value, the importance of the user experience, but it approaches them from an automation point of view from the very first step. Instead of asking “how do we manage this process,” it asks “how do we design this service so it runs and improves with as little manual effort as possible while still delighting the people who use it.”

The Service Automation Framework was born out of a fairly simple observation: the way most organisations delivered services no longer matched the way people had come to expect services to work, and the frameworks we relied on did not address that gap directly.

Automation had become too important to leave as a footnote. It deserved a framework of its own, and that is exactly what we set out to build.