The Hidden Reason ITSM-to-ESM Transformations Stall
by Dave Rosenlund
Atlassian Community Champion, CSX Masters (fka ITSM/ESM Masters)
Introduction
Most Atlassian customers don’t set out to build a unified Customer Service eXperience (CSX)—ITSM + ESM + CSM (& ITAM).
They start with ITSM.
A Jira Service Management implementation introduces better structure and automation. Intake becomes more consistent. Work is easier to track and discuss. SLAs introduce a shared expectation of responsiveness, and MTTR begins to move in the right direction. A modern system to automate and manage IT service management workflows is in place.
SLAs are being met. MTTR is going down.
From there, the next step feels obvious. If structured service delivery works in IT, it should extend naturally to the rest of the enterprise. HR, Legal, Finance, Facilities—all of them manage requests, workflows, and internal customers. Expanding the model appears less like a transformation and more like a continuation.
That assumption is where most ITSM-to-ESM expansion efforts begin to break down.
Not because organizations can’t scale tools. Jira Service Management scales extremely well.
They stall because enterprise service management only works where a corresponding service model already exists—and most of the enterprise doesn’t operate that way.
This Isn’t a Scaling Problem
The transition from ITSM to ESM is almost always approached as expansion. New service projects are created, portals are configured, request types are defined, and automation is layered in. From a tooling perspective, this works exactly as expected.
What doesn’t scale is the operating model.
The underlying assumption is that service management can be extended by replicating structure—that once a working system exists, it can be reproduced across functions with minimal friction. But ITSM didn’t succeed because structure was introduced. It succeeded because structure already existed, even if informally, and the tooling reinforced it.
Outside of IT, that assumption breaks down. Work is not organized as a set of clearly defined services with consistent intake and ownership. It is coordinated through context, relationships, and implicit understanding. Extending the tool into that environment does not extend the model. It makes the absence of that model visible.
Automation Amplifies the System You Already Have
Automation makes this gap more apparent, not less. When services are clearly defined, ownership is explicit, and intake pathways are consistent, automation behaves like orchestration. A single request can coordinate work across multiple teams with predictable handoffs and outcomes because the underlying system is coherent.
When those conditions are missing, automation takes on a very different character. Rules accumulate as edge cases are patched over. Routing logic becomes fragile. Teams begin working around the system because it cannot accommodate how the work actually happens.
Automation does not create a service model. It intensifies whatever model—or lack of model—already exists.
The Service Catalog Is the Foundation
(Even When It Isn’t Called That)
In IT, a service catalog is almost always present, even when it isn’t formally defined. There is a shared, if imperfect, understanding of what IT provides and how those services are accessed. Requests map—again, imperfectly but consistently enough—to specific outcomes, and there is at least a rough alignment between demand and ownership.
That implicit structure is what allows tooling to be effective. It creates a stable interface between the organization and the function delivering the service.
When organizations attempt to extend service management, they often replicate the interface—portals, forms, request types—without establishing the structure behind it. The result is a system that captures requests without organizing them. Demand becomes visible, but not intelligible.
On paper, many non-IT functions appear highly structured. Systems of record, compliance workflows, and case management processes are common. But that structure is usually optimized for control and reporting—not for service delivery. It does not translate cleanly into a service model.
IT Already Operates as a Service System
It’s easy to underestimate how much alignment already exists within IT. Even in environments that are considered immature, there is typically a baseline level of coherence. Services are recognizable, ownership is at least partially defined, and intake—however inconsistent—exists as a concept. Expectations around response and resolution are shared, even if not always enforced.
There is also a common language shaped by years of ITIL influence. That language establishes a mental model in which work is understood as something that flows through a system rather than something handled ad hoc.
Jira Service Management builds on that foundation. It does not need to create it from scratch, which is why value can be realized relatively quickly.
Most Work Isn’t Structured This Way
Other functions do not start from the same place. HR, Legal, and Finance all manage complex and often high-volume work, but that work is rarely structured as a set of services with clearly defined boundaries and repeatable intake mechanisms. Instead, it is mediated through context—email threads, conversations, meetings, and institutional knowledge that exists primarily in people rather than in systems.
That distinction matters more than it appears.
Knowledge Remains Tacit
In IT, knowledge is frequently externalized. It may be incomplete or uneven, but it exists in forms that can be referenced, improved, and incorporated into workflows. In many non-IT functions, the equivalent knowledge is distributed and tacit. Policies may be documented, but execution depends on judgment, experience, and context that are not easily codified.
In my experience, a great deal of enterprise service work still depends on that tacit knowledge, and frequently, it isn’t captured in the organization’s service management systems. The system captures demand without inheriting the knowledge required to resolve it efficiently.
Requests increase, but resolution does not scale in the same way. Without deliberate ownership of knowledge, the service interface becomes a bottleneck rather than a point of leverage.
This becomes even more important as organizations begin exploring AI-powered service delivery. Systems like Rovo depend on structured, accessible knowledge and clearly defined services to provide meaningful assistance. When knowledge remains tacit and services are undefined, AI has nothing reliable to reason over. Defining the service is what makes that knowledge usable—not just for people, but for the systems intended to support them.
Where ESM Expansion Breaks Down
As organizations push beyond IT, the same failure modes tend to surface. Services remain loosely defined, which means that requests lack clear categorization and everything begins to collapse into general intake. Ownership continues to reside with individuals rather than with the service itself, so accountability does not scale with volume.
In a conversation with Dhruvil Shah about this—he’s a fellow Atlassian Community Champion, and was a Senior Cloud Solution Engineer at Sophos at the time—this showed up very clearly. He observed that teams often stand up a service desk before they’ve defined the service. “Their system captures requests, but no one has agreed on what or how things will be delivered.”
At the same time, workflows proliferate. Each function configures the system to reflect how it already operates, and over time the platform begins to mirror the fragmentation it was intended to resolve. Naming conventions diverge, statuses lose shared meaning, and cross-functional coordination becomes harder rather than easier.
Governance Becomes the Constraint
Within IT, a single team can often maintain enough consistency for the system to remain usable. Across multiple functions, that consistency erodes quickly unless it is actively governed. What emerges is not a unified service model, but a collection of adjacent systems that share a platform without sharing a structure.
This is where governance stops being optional and starts becoming the constraint. Without it, “portal sprawl” sets in—multiple service desks, inconsistent request types, and overlapping entry points that confuse users and fragment demand.
As Stephen Mann of ITSM.tools has observed, many organizations have “strong standards inside IT, but operate completely differently everywhere else.” The platform is shared, but the model isn’t.
From the outside, this is often interpreted as an adoption issue. From the inside, it feels like friction. The system exists, but it does not reduce complexity; in some cases, it amplifies it.
The Partial Exception
There are environments where this transition works more naturally, and those environments share a common characteristic: the work is already structured in a way that resembles a service model. HR is often one of the clearest examples. Processes such as onboarding, offboarding, and case management are repeatable, bounded, and require a level of consistency that aligns with service-based delivery.
HR service requests are more structured and repeatable.
This does not make the transition trivial, but it lowers the barrier. The platform aligns with the structure instead of forcing it into existence. That alignment helps explain why ESM traction often appears first in functions like HR and much more slowly elsewhere.
The Real Work: Translating Functions into Services
“Progress doesn’t come from expanding the platform, it comes from stepping back and defining what the needed services are. Until that happens, extending the system just replicates existing problems at a larger scale.”
— Chris Green, Associate Director Global Client Support Services, StarCompliance
Where ESM succeeds, it rarely begins with demand from the business. It begins with recognition—usually within IT—that extending the platform is not sufficient. The work shifts from configuration to translation: understanding how a function actually operates and reshaping that work into something that can be expressed as a service.
In other words, this is not a purely technical exercise. It is organizational design work. It involves defining boundaries that did not previously exist, making ownership explicit where it was implicit, and introducing consistency without eliminating necessary flexibility. It requires authority, not just enablement, because it changes how accountability is expressed across functions.
Only once that translation has taken place does the tooling begin to deliver meaningful value.
Without it, the platform spreads, but the model does not.
This Is Where CSX Either Starts—or Stalls
The move from ITSM to ESM is not an isolated step. It is the foundation for a broader shift toward unifying service delivery across internal and external customers. Different terms are used—CSX, CSE—but the underlying idea is consistent: CSX is an operating model for coordinating service work across teams, systems, and functions—ensuring that every request moves through a defined workflow with clear ownership, visibility, and outcomes.
That unification depends on having a shared structure across functions. If ESM stalls, that structure never forms. IT operates within a system, while other functions continue to rely on fragmented approaches, and customer-facing teams build their own parallel processes.
The result is not a unified experience, but multiple operating models that coexist without aligning.
The Constraint Isn’t the Platform
It is tempting to attribute these challenges to limitations in tooling, but the constraint is structural. Service management requires defined services, clear ownership, consistent intake, and workflows that can be standardized without disrupting how work is actually performed.
IT has these conditions, even if imperfectly. Most other functions do not.
Expanding into ESM therefore requires building those conditions deliberately. That work is slower, more uneven, and more dependent on context than platform expansion. It is also the point at which many initiatives lose momentum.
What This Means for the Journey Ahead
Most organizations are earlier in this transition than they realize. Establishing ITSM is only the beginning. The move into ESM changes the nature of the problem from implementing a system to redesigning how services are structured and delivered across the organization.
That shift is not incremental. It is a change in how the organization defines work, assigns ownership, and enforces accountability across functions. It requires sustained effort, cross-functional alignment, and a level of authority that most tool-driven initiatives never reach.
Without that work, a unified service experience remains aspirational.
With it, the platform becomes a genuine lever for coherence over time.
Before you create the next project key, have you defined the service boundary?
📚 Further Reading
This is the first article in a "Beyond ITSM" series from the Atlassian Community Champions behind the virtual Atlassian Community Events chapter called CSX Masters.
Stay tuned for more.
See also…
-
What is Enterprise Service Management (ESM)? — A baseline view of ESM—useful for understanding how most expansions are framed as tooling rather than operating model change, Atlassian
-
What is a Service Catalog? — Reinforces why clearly defined services—not just request forms—are the prerequisite for scale, automation, and AI, ITSM.tools
-
Interview with an Expert: How Chris Green Helped Elevate Clarity, Speed, and Scale Globally — An interview with Chris Green showing how defining clear service structures and ownership transformed fragmented support into a more scalable, consistent service model within Jira Service Management, Atlassian Community
About the Author
Dave Rosenlund is an Atlassian Community Champion and the founder of the virtual Atlassian Community Events chapter, CSX Masters (fka ITSM/ESM Masters). He also helps out on the Program/Project Masters chapter and the Boston ACE.
In his day job, he works for Platinum Atlassian Solution Partner, Trundl.
Was this helpful?
Thanks!
Dave Rosenlund _Trundl_
2 comments