ITSM vs. ESM: How to Know Which One Your Business Needs (and Whether You Can Start with One and Scale to the Other)
September 2, 2026
Somewhere in the last few years, "ESM" started showing up in the same sentences as "ITSM," and a lot of IT leaders were left wondering whether it was a new category, a rebrand, or just another acronym vendors invented to sell the same thing twice. It's none of those. ITSM and ESM solve different problems, for different audiences, and mixing them up has a real cost: teams either buy more platform than they need, or they buy a tool that can't grow past the one department it was built for.
This article breaks down what each one actually does, how to tell which your company needs right now, and whether starting with one locks you out of the other later. Short answer on that last part: it shouldn't, but it often does, depending on what you bought.
Part of the confusion comes from how the terms get used in sales conversations. A vendor selling an IT-only tool will sometimes stretch "ESM-capable" to mean it technically has a form builder that other departments could use, even if nobody's built it out for them. A vendor selling a broader platform will sometimes use ESM as the umbrella term for everything, IT included, which makes it harder to tell what's actually different about the two disciplines versus what's just packaging. Cutting through that requires understanding what each term is supposed to mean on its own, independent of how any one vendor is pitching it.
ITSM has been around since the 1980s in some form, formalized through ITIL in the UK government's original IT Infrastructure Library. ESM is newer as a named category, gaining traction over roughly the last decade as companies realized the ticketing and workflow logic that worked for IT had obvious applications everywhere else internal requests piled up. That timeline matters: it's why most vendors in this space started as ITSM tools and are now trying to extend into ESM, rather than the other way around, and why so many of them handle that extension unevenly.
IT Service Management is the discipline of running IT as a service to the rest of the business, not just a department that fixes laptops when they break. It covers how incidents get logged and resolved, how changes to systems get approved and rolled out without breaking something else, how problems get diagnosed at the root instead of patched over and over, and how the assets and configurations behind all of it stay documented and current.
Most ITSM practices are built around ITIL: a framework for standardizing incident management, problem management, change management, and configuration management (usually tracked in a CMDB). If you want the clearest example of how two of those disciplines actually differ in practice, our incident vs. problem management guide walks through it. The scope is deliberately narrow: IT serving IT's users, with IT owning the tool, the workflows, and the escalation paths.
Enterprise Service Management takes the same logic, ticketing, SLAs, self-service portals, knowledge bases, workflow automation, and applies it to every department that fields internal requests: HR, Legal, Facilities, Finance, even Marketing. An employee submitting a laptop request and an employee submitting a contract review request go through the same kind of structured intake, the same visibility into status, and the same accountability for response time, even though completely different teams are fulfilling them.
The point isn't to make every department act like IT. It's to give the whole company one consistent way to ask for things and know where those requests stand, instead of a patchwork of email threads, shared inboxes, and spreadsheets that nobody outside the department can see into. We've written before about what that looks like in practice in how Halo makes ESM practical beyond IT.
Picture a new hire's first week. They need a laptop provisioned, a badge issued, a desk assigned, a benefits form processed, and access to three internal systems. Under ESM, all five of those requests live in one portal, each routed automatically to the right department, each visible to HR as a single onboarding checklist instead of five separate email threads they have to chase individually. Without it, that same new hire spends their first week pinging four different people on Slack asking whether anyone's looked at their request yet, and HR has no way to see the whole picture without asking around.
Both rely on the same underlying mechanics, tickets, SLAs, dashboards, and both increasingly lean on AI to triage and route requests automatically. The difference is who's asking, who's answering, and how far the platform's reach extends across the org chart.
Here's where a lot of companies go wrong, and it has nothing to do with picking the wrong framework. It's taking a tool that was configured for IT's workflows, terminology, and approval chains, and rolling it out to HR or Facilities without changing any of that. IT's ticket categories don't mean anything to a Facilities coordinator. IT's approval hierarchy doesn't match how Legal actually signs off on things. When the tool feels like it was built for someone else, adoption stalls immediately, and the department goes right back to email.
Take a Facilities team asked to log every repair request through a portal built with IT's categories: "hardware," "software," "network." None of those fit a broken air conditioning unit or a request to rearrange a conference room. So the coordinator does what anyone would do: keeps managing repairs the old way, through a phone call and a sticky note, and the portal sits there unused except when someone from IT checks the adoption dashboard and asks why the numbers look bad. That's not a Facilities problem. It's a rollout that skipped the one step that actually matters.
The fix isn't complicated, but it's a step teams skip because it feels slower: sit down with each department before turning anything on, learn their actual request types and who approves what, and build their catalog and workflows around that, not around IT's template. Departments that get this right see ESM as a tool built for them. Departments that don't see it as IT's tool, forced on them, and treat it accordingly.
The business case for getting this right isn't abstract. A 2025 industry survey from AXELOS and ITSM.tools found that 68% of organizations already have some kind of ESM initiative underway, and more than half consider their rollout well advanced. But other research points to a much wider gap between having ESM and having ESM done well: separate analysis suggests only around three in ten organizations have a truly formalized program that extends ITSM's discipline, not just its ticketing tool, beyond IT. Roughly half have stretched an existing ITSM or ticketing platform into other departments without fully rebuilding it for them, which tracks with the adoption problem above.
That gap costs real time. Employees still lose hours a week chasing status updates over email or Slack for requests that should have taken minutes to log and track. Facilities and HR teams still run their side of the business on shared inboxes and spreadsheets that nobody outside the department can search. And when a request does fall through the cracks, in Finance approvals, in onboarding paperwork, in a facilities repair ticket, there's no audit trail to show where it stalled or who owns the fix. None of that is a technology problem you can't solve. It's a scope problem: treating a company-wide need as if it were IT's problem alone.
Start with what's actually broken today, not with the acronym that sounds more advanced. A few signals point clearly in one direction or the other.
You need ITSM first if: your IT team is drowning in tickets with no visibility into recurring incidents, changes to systems get made without a documented approval trail, your asset and configuration data lives in someone's memory or an outdated spreadsheet, or you don't have SLAs at all for IT requests. If any of that describes your IT function, fixing it before touching anything else is the right call. You can dig into what a healthy version of that looks like in our breakdown of why service desk backlogs keep growing.
You're ready for ESM if: your IT service desk is already stable and predictable, but two or three other departments are visibly drowning in the same request-tracking chaos IT solved years ago. HR fielding onboarding questions over email. Facilities managing repair requests through a shared inbox nobody checks consistently. Legal tracking contract reviews in a spreadsheet that's always one version behind. If IT's problem is solved and everyone else's isn't, that's your signal to expand the platform's reach rather than buy IT another tool it doesn't need.
Some companies genuinely need both from day one, especially past a certain headcount, where request volume across departments has already outgrown email regardless of how mature any single team's process is. In that case, the question isn't which one to build first. It's whether the platform you choose can actually run both without becoming two separate systems that happen to share a login page.
Framing this as an either/or choice is where a lot of the confusion starts. ESM isn't a competing category you switch to instead of ITSM; it's ITSM's own logic applied further out. Every company running ESM well is still running ITSM underneath it for its IT department specifically. The real question was never "ITSM or ESM." It's "how much of the company needs this today, and how much will need it in eighteen months." Answering that honestly is what actually determines the sequencing, not a rule that says IT always goes first.
Yes, and this is the part most vendors gloss over because the honest answer depends entirely on what you bought. There are two credible paths here, and they're not the same.
The first path, and the one most often recommended by ITSM vendors with an IT heritage, is to build ITSM maturity first: get incident, problem, and change management solid, get your CMDB accurate, and use that as the foundation before extending the same principles to other departments. This works well when IT genuinely needs the groundwork and other departments aren't yet feeling enough pain to justify the change management effort of a rollout.
The second path, favored by platforms built ESM-first, skips the sequencing entirely: pilot with whichever department is in the most pain right now, IT or otherwise, prove the model works, then expand department by department based on where the next fire is. Neither path is wrong. What matters more than which one you pick is whether your platform can actually support the transition without a re-buy.
This is where a lot of companies get burned. Plenty of ITSM tools are built specifically for IT workflows, IT terminology, and IT's approval logic, and extending them to Legal or Finance means fighting the tool the whole way, or paying for a separate ESM product that doesn't share data or a login with the ITSM tool you already have. That's not scaling. That's running two platforms and calling it one strategy. If you're already evaluating options with growth in mind, our guide to choosing an ESM platform that scales covers the specific traps to check for before you sign anything.
Assuming your platform can technically support both, the rollout itself still needs real work, and skipping it is exactly how the "mistake" from earlier in this article happens. Before turning ESM on for a new department:
Our own experience helping clients through Halo's self-service portal rollouts backs this up directly: adoption stalls at roughly a quarter of employees when a portal is dropped on a department without this groundwork, regardless of how good the underlying platform is.
Digital transformation spending across Latin America is accelerating faster than most global benchmarks: South America's digital transformation market alone is tracking a 17.69% compound annual growth rate through 2030, and IT services spending in markets like Brazil and Mexico is growing in the double digits annually, with Mexico's IT services sector forecast to grow 11.87% a year through 2030. That growth is pulling more mid-size companies into a position where manual, email-based request handling across departments simply doesn't scale anymore, often before those companies have the internal maturity or headcount to build a formal ESM program from scratch the way a large enterprise would.
That's exactly the environment where the platform choice matters more than the sequencing debate. A company growing at that pace doesn't have time to re-platform in eighteen months because the ITSM tool it picked can't extend past IT, and it usually doesn't have a dedicated ESM team to manage a second product on top of whatever IT already runs. The practical answer for most companies at this stage in the region isn't "buy the most advanced ESM suite available." It's "buy a platform that can grow with you without a second procurement cycle."
Halo runs IT Service and Enterprise Service as two configurations of the same platform, on one engine and one license, not as two products you buy separately and try to connect later. That matters directly to everything above: if you start with IT Service to fix the problems in your service desk, and six months later Legal and Facilities are asking for the same visibility, you're turning on a solution within a platform you already own, not migrating data into a second system or negotiating a new contract.
Halo AI runs across both, so the same automation deflecting routine IT tickets can also route a facilities request or an HR question without separate configuration work. And because it's ITIL-aligned with a no-code setup, IT can stand up a department's catalog without writing custom integrations for each one. Halo is named in the 2025 Gartner Magic Quadrant for AI Applications in IT Service Management and runs in 5,000+ organizations across 100+ countries, so the platform has been proven at both ends: pure IT service desks and full enterprise-wide rollouts.
That range matters across the kinds of organizations we work with in Latin America and the Caribbean. A manufacturing company under pressure to get plant-floor IT support under control has a different starting point than a university juggling Facilities and Student Services requests alongside its help desk, or a retailer scaling HR onboarding and IT provisioning at the same pace during a growth push. What they have in common is that none of them need to pick a different vendor the moment their needs expand past IT. They turn on a solution that's already part of the license they have.
Before a single sales call, sit down internally and answer these honestly:
The honest answers to those four questions will tell you more about which path fits than any vendor pitch will.
Do I need to fully mature my ITSM practice before I can start ESM? No. It helps, but it's not a requirement. Plenty of companies pilot ESM in a department outside IT first, especially when that department's pain is more urgent than IT's. What matters is picking a platform that supports either sequence.
Is ESM just ITSM with a different name for marketing purposes? No. The underlying mechanics overlap, tickets, SLAs, workflows, but the scope, ownership model, and success metrics are genuinely different. Treating ESM as a rebrand is how companies end up rolling out an IT-shaped tool to departments it wasn't built for.
Can small or mid-size companies justify ESM, or is it only for large enterprises? Request volume, not headcount, is the real trigger. A 200-person company with four departments drowning in email-based requests needs ESM more than a 2,000-person company with one well-run IT desk and no other department in visible pain.
What's the biggest risk in scaling from ITSM to ESM? Assuming the ITSM tool you already have will extend cleanly. Some do. Many don't, and the ones that don't turn "scaling" into a second implementation project with a second budget line.
Does IT have to own ESM once other departments are on the platform? IT usually stays the platform steward, handling the underlying configuration and integrations, but day-to-day ownership of each department's catalog, forms, and approval flows should sit with that department. If IT ends up owning every workflow across the company, adoption tends to suffer for the same reason a badly-scoped rollout does: it still feels like IT's tool.
How long does it typically take to extend ITSM into a full ESM rollout? There's no fixed timeline, and be wary of any vendor who quotes one without asking about your departments first. A single well-scoped department, like Facilities or a small HR team, can often be live in a matter of weeks once its catalog and workflows are mapped. Rolling out across four or five departments company-wide is a longer, phased effort, closer to a couple of quarters than a couple of weeks, precisely because each one needs its own discovery work done properly.
Whether your IT desk needs to get its own house in order first, or you've got two other departments already drowning in email while IT hums along fine, the right next step is the same: get an outside read on where the real pain is before you commit to a platform. Talk to our team and we'll help you map it out.
