Blog: From ITSM to ESM: Taking Service Management Beyond IT

Having recently wrapped up an IT service management (ITSM) implementation for a large police force built on Agentforce IT Service, I’ve been thinking about what comes next. Not just for the force, but for organisations in general. ITSM has traditionally focused on making it easier for IT teams to manage requests, resolve issues and keep services running. But the need for simple, well-managed services doesn’t stop at the IT desk.
Employees interact with teams across an organisation every day, whether they’re joining the business, requesting equipment, getting something approved or simply trying to find the right information they need. And as AI agents become more available and capable for supporting these interactions, it opens up an interesting question: how far can we take the service management principles that already work within IT?

That’s where enterprise service management (ESM) enters the conversation. And having seen agentic ITSM in practice, I’m particularly interested in what needs to happen behind the scenes to make that next step work.

ITSM vs ESM: what's the difference?

Before getting into what needs to happen behind the scenes, let’s put the difference between ITSM and ESM into a real-world scenario. You’re an employee who needs help. With ITSM, your laptop suddenly stops working. You raise a request, it’s routed to the IT team, and you can track its progress through to resolution. Now imagine you need to update your parental leave, request a new access pass or get a purchase approved. ESM takes those same service management principles beyond IT, giving teams such as HR, Facilities and Finance a structured way to receive, route and manage these requests.

Same approach, different scale.

Most treatments of the ITSM-versus-ESM question land on the same sensible conclusion: they're not competitors, they're stages. Get IT service management right first - stable processes, a service desk that actually resolves things, credible metrics - and only then extend that discipline outward into ESM. AI usually shows up in that story as an amplifier: automation that sharpens ITSM's ticket handling, and orchestration that stitches together the multi-department workflows ESM depends on.

I think that sequencing is right. What I want to add isn't a different answer to "ITSM or ESM" - it's the layer underneath it. Deciding you're ready to move from one to the other is a maturity question. Actually building the thing that makes the move work is an architecture question, and it gets harder, not easier, once agents are doing real work instead of routing tickets.

Agentic AI raises the bar on the ITSM foundation, it doesn't lower it

There's a tempting shortcut in every ITSM programme under pressure: bolt on an AI agent early to show quick wins, even while the underlying service data is still messy. It's tempting because a chatbot in front of a bad process still looks like progress in a demo.

An agent handling first-line resolution - deciding what a request is, whether it can fix it, and who to hand it to if not - is only as trustworthy as the data, configuration, entitlements and knowledge it's reasoning over. And that information won't necessarily live in one place. It could span asset records, knowledge articles and other systems across the organisation.

Feed it an incomplete asset record or a stale knowledge article and you increase the risk of incorrect decisions, poor responses or unnecessary escalation. So the foundational discipline ITSM has always emphasised - clean asset records, documented processes, accurate entitlements - isn't a box to check before the "real" AI work starts. It's the thing the agent stands on, and every gap in it becomes a gap in what the agent can be trusted to do unsupervised.

As agents take on more responsibility, bringing the right information together and making sure it's accurate, governed and available in context becomes part of the AI foundation itself. That's worth saying plainly to anyone tempted to treat agentic capability as a shortcut past the unglamorous foundation-building phase. It isn't. If anything, it raises the stakes on getting that phase right, because the cost of skipping it now shows up in the decisions and actions you're increasingly trusting agents to make.

What does agentic ESM look like in practice?

One request. Three departments. It helps to walk through what this looks like once you're past IT and into ESM territory. Take something ordinary: a new hire starting Monday needs a laptop provisioned, building access, and a desk assigned. In a ticket-based world, that's three separate requests to three separate queues, and the new hire's first week is spent following up on all three.

In an agentic ESM setup, one request triggers work across domains: an IT-scoped agent provisions the laptop and checks entitlements against the new hire's role, an HR-scoped agent confirms start date and role details, and a facilities-scoped agent assigns a desk and triggers badge access. None of that requires one all-knowing "enterprise agent." It requires domain-scoped agents that can each act within clear boundaries and hand off cleanly - to each other, and to a person when something falls outside those boundaries, like a role that doesn't match any standard access template.

Behind that seemingly simple experience is another consideration: those departments are unlikely to be working from one system. Employee information might sit in an HR platform, asset records somewhere else and building access in another application entirely.

Extending service management across the enterprise doesn't mean moving everything onto one system. The architectural challenge is connecting those systems in a controlled way, so agents can access the information and actions they need without passing that underlying complexity on to the employee. MuleSoft, for example, can provide that connectivity across applications, data and APIs while allowing departments to continue using the technology they already rely on.

The coordination is the product; the individual tasks were never the hard part.

The architecture behind the move from ITSM to ESM

Once IT service management is solid and an agent is handling meaningful volume, the instinct when extending into a second domain is to treat it as a platform question: stand up a shared portal, add HR's catalog items, add Facilities' request types. That's necessary, but it's not what determines whether the expansion actually works.

What carries over is the agent architecture itself: how it retrieves context for a given domain, which data and systems it can access, what actions it's scoped to touch, where it's required to hand off to a person, and how its decisions get audited afterward.

As ESM expands across departments, that increasingly becomes a data and integration question too. Agents need trusted information to reason over, but they also need a controlled way to reach the systems where work actually happens. Data 360 can help bring together and harmonise the context agents need, while MuleSoft can connect the applications, APIs and actions sitting behind it. Agentforce then provides the layer through which agents can reason and act within the boundaries you've defined.

Extending from IT to HR isn't "build HR a form" - HR's requests were never the bottleneck, the coordination and judgment around them were. Handing that coordination to agents means defining, domain by domain, the same things you had to define for IT: entitlement boundaries, escalation triggers, and a clear owner for what happens when an agent gets it wrong. Coordinating a workflow like the onboarding example above, across IT, HR, and Facilities, is solution architecture work - deciding where agents hand off to each other and where a human has to be the one to say yes - and a maturity framework can point you toward doing it, but it can't do it for you.

Three things to get right before extending agentic AI beyond IT

Beyond the general readiness signs (is IT running smoothly, is the organisation structured for cross-functional work, etc) there are three lessons I'd carry forward before extending an agentic foundation into a second domain.

1. Look beyond how much your agents deflect

First, track how often the agent's resolutions get overridden or escalated after the fact, not just how many requests it deflects. A low override rate over a sustained period tells you the underlying data and guardrails are trustworthy enough to extend into a domain with less institutional knowledge to fall back on. A high one tells you the current foundation still needs work, regardless of how good deflection volume looks on a dashboard.

As agents begin drawing context from more departments and systems, this becomes even more important. Connecting more information isn't enough; that information needs to be accurate, current, appropriately governed and relevant to the task the agent is trying to complete.

2. Build governance around what agents do, not just what people do

Next, check whether your governance model already treats agent actions as something that gets reviewed, not just human actions. Extending into HR or Legal means an agent will eventually touch more sensitive data and more consequential decisions than a password reset. If the audit and escalation model was designed around IT's risk profile and never revisited, that's the gap to close before a second domain goes live, not after.

That also means being explicit about access and accountability: what information can an agent see, which systems can it interact with, what actions can it take, and at what point does another agent or a person need to step in?

3. Make human intervention part of the learning loop

And lastly, look at whether escalations actually feed back into the system. When a person overrides an agent or resolves something it couldn't, that correction should update the knowledge base or the routing logic, not just close the ticket. Without that loop, every new domain starts by relearning the same lessons IT already paid for.

Where this leaves the ITSM to ESM sequencing question

None of this argues against starting with ITSM and earning your way to ESM - that order still holds, for the same reason it always has: you need a working foundation before you ask another department to trust it. What changes with agentic AI is what "working foundation" needs to mean. It's not just documented processes and stable SLAs (service level agreements) anymore; it's data clean enough for an agent to act on unsupervised, connected systems that give it access to the right information and actions, and a governance model built to review autonomous decisions before you hand a second department into that same system.

The opportunity is to take what already works within IT and extend that experience across the organisation. But as agents take on more of the coordination and action behind those services, the architecture supporting them has to grow with that ambition.

At Infomentum, our team is helping organisations put these principles into practice, combining service design, Agentforce, data and integration to build the foundations for more connected, intelligent services. If you're strengthening your ITSM environment today or considering how it could extend into ESM tomorrow, we'd be happy to share what we're learning from real-world delivery.