Enterprise Service Management: From ITSM to AI-Executed ESM
A new hire's first day generates a laptop request, a payroll setup, and three access tickets. Each lands in a different queue with its own status. Nobody can see whether the person will be able to work by Thursday. Many enterprise service management (ESM) programs delivered that experience when they copied the IT service desk into HR, finance, and facilities.
The alternative runs the same request as one process. An AI agent reads the free-text request. Deterministic logic, which produces the same output for the same input, sequences the steps. A manager approves only where judgment is required. The architecture you fund decides which outcome you get. It also decides how much of your AI spend you can forecast.
This article traces how ESM grew out of IT service management and what an AI-executed service process needs to get right.
How Enterprise Service Management Grew Out of ITSM
ESM grew out of IT service management (ITSM) by applying its practices and tooling to work outside IT. Business functions gained a common model for governing internal requests.
ITSM is the discipline of delivering and governing IT services through incident, request, change, and knowledge management. An ITSM platform provides workflow management and automation for those practices, with a system of record at the center. The framework beneath it, the IT Infrastructure Library (ITIL), traces back to a 1989 UK government publication.
ESM takes those principles, practices, and technology into functions outside IT. ITIL 4, released in February 2019, gave that extension a wider frame. It organized its guidance around the Service Value System (SVS), a model of how an organization's components and activities work together to create value. It also addressed service management in general.
In ESM programs, organizations modeled HR onboarding, facilities repairs, legal intake, and purchase requests as services. Each got a catalog entry, a queue, and a fulfiller.
Vendors built that model inside the platform IT already ran. HR, finance, and legal each received their own queues and workflows, and eventually their own AI agents. The ambition has since grown to connecting business, corporate, and technology services through shared governance, data, and automation. The tooling beneath that ambition was built for the queue.
Where the Ticket-and-Queue Model Stalls
The onboarding example shows the structural problem in miniature. Each department sees the status of its own ticket. No system holds the dependency between the laptop, the payroll record, and the access grant. Expanding ITSM into ESM on this model multiplied queues without connecting the cross-functional work.
Costs compound too. When licensing is tied to seats, every function you onboard adds seats. AI priced by usage adds variable charges on top. Token- and inference-based pricing bills for units of text and model computation. Difficulty budgeting for it ranked as the single largest barrier to evaluating AI vendor pricing in IDC's May 2026 survey of more than 1,400 IT leaders. Under that model, every new user who adopts the tool raises the bill. Success, billed as overage.
Each new module also brings its own data problem. Adding a function to an existing platform can mean adding another system, and your data then needs more pipelines into and out of it. Sanofi's Chief Digital Officer Emmanuel Frenehard told Fortune he rejected that model: "I don't want to have Salesforce agents, speaking to ServiceNow agents, going to speak to SAP agents."
Deterministic and Probabilistic Steps in AI-Executed ESM
AI-executed ESM assigns each decision step to the kind of logic that fits it. Some steps call for deterministic rules, some for an AI model's interpretation, and some for human judgment. Deployments that blur those assignments let a model decide approvals and postings.
Deterministic steps include routing by cost center, checking an approval matrix, and posting to a ledger. Same input, same output. Every time.
Probabilistic logic, the kind a large language model (LLM) runs on, interprets a goal and chooses a path. The same input can produce different outputs on different runs.
That variability helps when a step reads an unstructured request, extracts fields from a contract, or classifies a request against a taxonomy. It becomes a liability when a step decides whether a $40,000 purchase clears the approval hierarchy. The deterministic and probabilistic split is what separates AI-executed ESM from a chat interface added to a ticket queue. Deterministic process logic owns the sequence and the decision points. The process calls AI agents at steps that need interpretation. People own judgment and exceptions.
Most organizations are still making this architecture decision. Only 17% of organizations have deployed AI agents, and more than 60% expect to within two years, according to survey data in Gartner's agentic AI Hype Cycle. The same report places agentic AI at the Peak of Inflated Expectations and states that "fully autonomous agents are not ready for the majority of enterprise use cases." For the majority still planning, governance design comes before the first deployment.
The cost of getting it wrong is already forecast. Gartner predicts that by 2027, 40% of enterprise organizations will demote or decommission autonomous AI agents after production incidents expose missing governance controls. Gartner analyst Shiva Varma traces the failure to treating agent governance as binary, with every agent either locked down or fully trusted.
Setting autonomy per process step removes that binary. Deterministic rules keep control of routing, approvals, and irreversible actions. Agents interpret unstructured material only at bounded steps. No single trust setting has to cover the whole process.
The process owner decides where each human review checkpoint sits and which decisions the agent may handle alone. That deterministic layer grows more important as volume grows. An ungoverned decision can repeat many times before anyone reviews it.
What AI-Executed Service Requests Need to Record
The EU AI Act already specifies what high-risk AI systems must record, and that list works as a practical standard for any AI-executed service process. Article 12(1) requires that "high-risk AI systems shall technically allow for the automatic recording of events (logs) over the lifetime of the system." Articles 19 and 26(6) require providers and deployers to keep those logs for at least six months.
Those obligations apply to stand-alone high-risk systems listed in Annex III, the Act's list of specified high-risk use cases, from December 2, 2027. The Digital Omnibus on AI, a 2026 amendment to the Act, moved that date back from August 2026.
Many service requests will fall outside high-risk classification. The fields the Act lists still make a useful template. Article 12(3), written for remote biometric identification systems, names four fields: the start and end time of each use, the reference data the system checked, the input data behind a result, and the identity of the person who verified the output.
A process log for an AI-executed request needs the same shape. It identifies the agent and workflow the process invoked, the inputs, the result, and the reviewer. It stays available for the full retention period, so anyone can reconstruct the run.
Choose the Architecture Before the Next Renewal
ESM set out to give the whole company one operating model for service requests. Ticket-and-queue tooling falls short when it adds a queue per function and a seat per fulfiller, with metered AI charges on top. Logging obligations are phasing in, and consumption-priced AI costs scale with adoption. Choose the architecture that will carry your service processes before the next module renewal locks in another multi-year term.
Elementum is the Enterprise AI Apps Platform that allows you to deploy AI, deterministic workflows, and human-in-the-loop actions at scale, without moving your data off of your data cloud. Adoption can start at the front door your employees already use, alongside the service platform you run today. That front door can be Elementum, Microsoft Copilot, Claude, or a corporate GPT. Each use case you move to us replaces the application and retires the licensed system. The estate gets smaller.
Our deterministic Workflow Engine sequences every step. Our AI Agents run only where reasoning is required, under guardrails the process defines, including configurable decision thresholds and input validation on every model interaction. We run your existing agents inside the process. We log every agent action.
We run natively inside your own cloud data platform under your existing access controls. Snowflake is live today, and Databricks is a live second track, currently a minimum viable product (MVP). Our Zero Persistence architecture means we never train on, replicate, or warehouse your data. Nothing is retained at the execution layer, the runtime that carries out a process, once a run completes. We query source systems in place.
Pricing is a flat annual fee per application, with no per-seat license, no per-conversation charge, and no per-action charge for AI. Adding employees to an application doesn't add to the license line.
Many of our customers start with one workflow, prove the savings, and expand into adjacent processes. At Sanofi, we replaced the procurement workflow that ran on Coupa. Global enterprises including Sanofi, Under Armour, and Elevance Health run on Elementum.
Contact us to map AI-executed service processes into your ITSM architecture and the rest of your AI roadmap.
FAQs About Enterprise Service Management
These are the questions IT and operations leaders most often raise when they extend service management beyond IT.
How Should You Distinguish ITSM From ESM?
ITSM and ESM differ in scope. ITSM covers the delivery and governance of IT services: incidents, requests, changes, and knowledge. ESM applies the same practices and tooling to HR, finance, facilities, legal, procurement, and any other function that fields internal requests. ESM includes ITSM, and an ITSM platform doesn't automatically extend to ESM.
Does Enterprise Service Management Replace Your ITSM Practices?
Enterprise service management keeps your ITSM practices and extends them across the business. An AI-native ESM model changes the application layer. A deterministic process takes over from the ticket queue as the unit of work, and you retire existing modules as work moves to the new process.
What Does Agentic Enterprise Service Management Mean for Your Team?
Agentic enterprise service management means AI agents read intent, gather context across systems, and act inside your service processes. People stay involved at defined checkpoints. For auditability, deterministic process logic stays in charge of sequence and decisions and calls agents only at steps that require interpretation.
Will AI Agents Replace Your Service Desk?
AI agents shift your service desk's work toward exceptions and judgment calls. Your team keeps those cases and the high-impact incidents. The process routes each one to a named reviewer with the context already gathered.
Keep Reading
The Enterprise Guide to Agentic AI for ITSM
Agentic AI for ITSM: A Practical Architecture for Enterprise IT
AI for ITSM: How Agentic Orchestration Modernizes IT Service Management
Run an ITSM Migration Off ServiceNow in Five Phases
ITSM Workflow Automation: Combining Agents, Rules, and Human in the Loop
How Companies Use Agentic AI Across the Enterprise