ITSM vs ESM: what is the difference and when is ESM worth it?

ITSM stands for IT service management: the way the IT department delivers services to users, with tickets, agreements and processes. ESM stands for enterprise service management: exactly that same way of working, but applied to other departments such as HR, facilities or finance. So the difference is not in the approach, but in the reach. ESM is ITSM that grows beyond the borders of IT.

That sounds simple, and at its core it is. The hard part is knowing when to take that step and when to leave it. This article explains the difference clearly and shows when ESM pays off and when it is overkill.

The same foundation, different departments

What ITSM and ESM share is the base. In both cases work arrives at a central place, is assigned, handled and reported back, and you can see whether it is going well. That foundation is exactly what we describe in what is service management: a place for the work, agreements about handling, and visibility into quality.

With ITSM the customers are employees with an IT question: a stuck password, an application that will not work, a new laptop. With ESM you widen that same model. A new employee who needs a desk, an access badge, a payroll account and a laptop on their first day touches HR, facilities and IT at once. In an ESM setup that runs as one request through the organization instead of as four separate emails.

The underlying platform is often the same. Most modern ITSM tools can handle ESM too: you create extra service departments, with their own forms, their own handlers and their own agreements, behind the same portal. How to pick a platform that grows with you is covered in choosing an ITSM or ESM tool.

Where ESM genuinely adds value

ESM is not a goal in itself. It pays off in situations where departments touch each other's work and the handover is currently messy. A few recognisable examples beyond IT.

Onboarding and offboarding. The joiner-mover-leaver process is the classic example. A new employee triggers actions at HR, IT and facilities. If those three work separately, something is always missing: the laptop is there but the badge is not, or the account exists but the workplace is not set up. In an ESM setup, one request in HR automatically triggers the tasks at the other departments. Everyone sees the same request and its status.

Facilities requests. A broken heater, a meeting-room booking, a move within the building. These requests often run through email or a separate system, with no visibility into lead time or handling. In the same portal as the IT requests, they become measurable and traceable.

HR questions. Questions about leave, expenses or terms of employment reach HR by email and in the corridor. With a service desk approach, HR gains a grip on what is going on, can put frequently asked questions into a knowledge base, and sees where most of the time goes.

The common thread: ESM adds value where multiple departments deliver a service together, or where a department beyond IT experiences the same chaos IT solved years ago with tickets. What that expansion looks like in practice is covered in ESM beyond IT.

When ESM is overkill

Just as important is knowing when not to do it. ESM is overkill in a few situations.

Your IT service management is not solid yet. If the service desk still struggles with the basics, it is unwise to roll the approach out to other departments. You would be exporting your own chaos. Get ITSM running first. Where you stand is determined with an ITSM maturity assessment.

The department does not want it. ESM only works if the receiving department sees the value and will use it. An HR team that did not ask for it and experiences it as an extra burden will avoid the portal. Without an internal owner in that department it becomes an empty shell.

The volume is too low. A department that gets a handful of requests a month does not need a service desk setup. A shared mailbox with a good agreement is enough. Adding process where there is no volume costs more than it delivers.

You expect the tool to solve the problem. If the collaboration between departments is broken in substance, a shared portal will not fix that. The tool makes visible what happens, but the agreements about who does what you have to make yourself.

The principle behind this is the same as with ITSM: only add process and tooling where it delivers something. That is service management without ITIL dogma in practice.

How to take the step, if you take it

If you go for ESM, start with one department that has a concrete problem and enough volume to make it worthwhile. HR at onboarding is often a good first, because the pain is visible and the process touches IT anyway.

It is important to set the service up in the language of the receiver. An HR employee does not think in incidents and changes, but in "register new employee" or "request leave". A service catalogue in customer language makes the difference between a portal that gets used and one that gets avoided. Also arrange an owner in the department itself, someone who guards quality and is the point of contact. Without that ownership every expansion fades.

Only expand to a next department once the first runs and demonstrably delivers something. That way ESM grows organically with the organization instead of as a big programme that lands everywhere at once.

Frequently asked questions

What is the difference between ITSM and ESM? ITSM is service management applied to IT services. ESM is the same approach applied to other departments, such as HR, facilities and finance. The way of working is the same; the difference is the reach. ESM is ITSM that grows beyond the borders of IT.

Do you need a separate tool for ESM? Usually not. Most modern ITSM platforms support ESM too: you create extra service departments with their own forms, handlers and agreements, behind the same portal. During a selection, do check whether the platform properly separates roles and permissions per department.

When is ESM overkill? ESM is overkill if your IT service management is not solid yet, if the receiving department does not want it, if the volume is too low, or if you expect the tool to solve a collaboration problem. Only add process where the volume and the will are present.

Where do you start with ESM? Start with one department that has a concrete problem and enough volume, often HR at onboarding. Set the service up in the language of the receiver, arrange an owner in that department, and only expand to a next one once the first demonstrably runs.

Not sure whether ESM is worth it for your organization? book a call and we will look together at whether the pain and the volume justify it. For support with tool choice and rollout, see our service management services.

Further reading

• Enterprise service management (Wikipedia)
• IT service management (Wikipedia)
• What is ESM? (Atlassian)
• ITSM glossary (Gartner)