ITSM vs ESM becomes a real problem when chaos no longer ends with IT
ITSM structures the way IT services are managed: tickets, outages, requests, changes, service levels, and operational knowledge. The approach itself remains useful even in a broader service model. The difficulty begins when other departments also need similar mechanisms, but each of them builds those mechanisms from scratch on its own.
HR creates a separate form for employee requests. Administration manages office equipment and access requests. Procurement tracks purchase needs in a spreadsheet. Finance asks for additional data by email. Legal records case statuses somewhere else again. From the perspective of individual teams, this may look rational. From the organization’s perspective, however, several parallel ways of performing very similar work begin to emerge.
This is where ESM, or Enterprise Service Management, enters the picture. It is not “ITSM for HR” under a different name. It is the use of proven service management principles to structure internal processes in other areas of the organization as well.
The difference matters in practice. If more departments need request intake, responsibility assignment, statuses, approvals, deadlines, and communication history, it becomes difficult to justify creating a separate mini-system for each of them. It becomes even more difficult to manage the whole picture later.
This broader context is visible in the way ITSM systems create value. Their value does not come only from registering tickets, but from introducing a clear service model. ESM extends that logic to the areas where other business functions start needing the same kind of operational discipline.
The first signal that ESM is needed is the same mechanism repeating across departments
The most obvious signal is repeatability, and it does not have to depend on company size.
If HR, administration, procurement, and IT independently create forms, contact inboxes, handover procedures, and status lists, the organization is probably solving the same problem several times. The name of the request changes, but the mechanism remains very similar: someone reports a need, someone qualifies it, someone is responsible for execution, approval may be required, and the request should eventually be closed and possible to reconstruct later.
At first, this kind of fragmentation does not have to look dangerous. One department uses an inbox, another uses a form, a third uses a spreadsheet. The cost becomes visible only when the number of dependencies between processes starts to grow.
Employee onboarding is a good example. From HR’s perspective, the process includes employee data and formalities. IT is responsible for creating accounts and preparing access. Administration may handle the workstation, ID badge, or equipment. The manager approves the scope of permissions, and procurement may become involved if the required equipment is not available.
When each of these steps is handled in a separate channel, onboarding stops being one process. It becomes a set of local activities that concern the same person but are managed independently.
This is exactly the type of dependency that should trigger a discussion about ESM. The point is not to make every department work in the same way. The point is to introduce a shared logic for transferring responsibility.
When request status exists only in an employee’s head, the problem is no longer about the tool
The second signal is less visible, but usually more expensive operationally: the lack of shared information about the status of a request.
In many organizations, answering the question “what stage is this request at?” requires sending a message to a specific person. During that person’s absence, the process loses visibility. Formally, the request still exists, but the organization has no simple way to determine what has been done, what is missing, and who should act next.
This is an important distinction. The problem is not email or spreadsheets as such. These tools may be sufficient in simple cases. The problem appears when the status of a process depends on the knowledge of the person currently handling it, instead of on data available to other participants.
In a structured service model, a ticket or request should have a clear status, owner, and history. This means the process does not have to be reconstructed from correspondence. In a less organized model, the role of the system is played by a person who remembers who received the message and what should happen next.
This arrangement can work surprisingly long. Usually until the first holiday, reorganization, or clear increase in request volume.
ESM does not eliminate human responsibility. On the contrary, it makes responsibility visible to other people involved in the process.
Many contact channels become a problem when they create many versions of the same request
Another signal is the growing number of channels through which employees submit needs.
The fact that an organization uses email, forms, a portal, or messaging tools does not automatically mean there is a problem. Users should be able to contact the organization in a way that fits the situation. Complications begin when each channel starts a separate version of the process.
An employee reports a problem by email. Then they ask about it in a messaging tool. A few days later, they contact a specific person directly. Because the request has no shared identifier, different people begin working with different fragments of information. Part of the context is in an email, part of it is in a private conversation, and the final decision lands in a spreadsheet.
In that situation, the organization no longer has multiple contact channels. It has multiple versions of the truth.
A similar problem appears within IT itself and is closely related to the shift from sorting messages to managing tickets. In the ESM context, the mechanism is the same, but it affects more departments. The entry channel may differ, but further handling should still lead into one controlled process. This is also why a structured helpdesk environment matters: the channel should not become a separate process every time.
ESM becomes necessary when a process moves across several departments more often than occasionally
The most important internal processes rarely respect the organizational chart.
A change in an employee’s position may require action from HR, IT, the manager, and administration. The purchase of a new tool may involve a business department, IT, security, procurement, and finance. An access request may require approval from the system owner and then execution by an administrator.
At a small scale, these dependencies can be handled manually. The need for a more structured model becomes clear when cross-departmental processes stop being exceptions.
In such conditions, every local optimization has limited value. HR may manage its part of the process very well, but still not see whether IT has completed the next step. IT may close its task even though the overall business request remains open. A manager may not know that their approval is blocking progress.
ESM structures precisely this level of work. It makes it possible to think about the process as a service delivered to the user, not as a sequence of independent activities performed by separate departments.
This is a subtle change, but it has significant operational consequences. In a siloed model, each team optimizes its own fragment. In a service model, what matters is whether the user’s need has been handled from beginning to end.
A growing number of tools can hide a cost larger than the license itself
Sometimes the need for ESM becomes visible during a review of applications used across the organization.
It turns out that several departments use different systems for forms, workflows, request handling, or internal knowledge bases. Each tool has an owner, configuration, permissions, integrations, and data. Each also requires maintenance, and users may need separate training. As a result, the cost of fragmentation extends beyond the license price.
This does not automatically mean that all applications should be replaced with one platform. Such a decision may be just as oversimplified as the earlier fragmentation. Not every process is suitable for transfer into an ESM model, and a specialist system may be necessary because of functional scope or regulatory requirements.
It is still worth checking whether some applications exist only because individual departments needed a simple mechanism for receiving and handling requests.
At this point, it is useful to look at the real cost of ITSM systems. The same logic applies to ESM: the cost of a tool does not end with the subscription. It also includes administration, integrations, process maintenance, training, and the time spent manually transferring data between systems. This broader cost perspective is discussed in the article on the true TCO of ITSM systems.
ESM makes sense when consolidating the service model actually simplifies work. Reducing the number of applications is not sufficient justification on its own.
ESM implementation does not start by moving every department onto one platform
One of the more common mistakes is treating ESM as a project that starts with the assumption: “we are implementing one system across the whole company.” That starting point is too broad.
Implementation can be approached in stages. At the lowest level, each department handles requests using its own methods, and handovers between teams are manual. The next stage begins when selected processes are described and consistent rules are introduced for request intake, statuses, and responsibility.
Only later does it make sense to build shared service catalogs, automation, cross-functional reporting, and more complex interdepartmental processes.
The order matters because ESM will not fix a process that the organization cannot describe. The lack of a clear answer to the question “who approves this request?” will not disappear after a platform is launched. It will simply be recorded in a more structured interface.
That is why, before extending ITSM beyond IT, it is worth starting with several highly repeatable processes with clear responsibility. A good candidate may be onboarding, an access request, an equipment request, or the handling of standard administrative matters. Not because they are impressive, but because they make it easy to check whether a shared model actually reduces the number of manual handovers.
A broader view of this approach is also presented in the article on how to extend service management beyond IT without another platform.
Readiness for ESM is visible in process quality, not in the number of interested departments
Before starting an ESM project, several aspects are worth checking.
First, it is necessary to verify whether the organization can identify specific processes that are repeatable and possible to evaluate. A general statement such as “we want to improve HR” is too broad. A much better reference point is a process where it is clear who submits the request, what information is required, who is responsible for execution, and when the request can be considered complete.
The next condition is identifying the process owner. This is not only about the system administrator. Someone must be responsible for the rules of the service and for making decisions when the process needs to change.
The quality of input data is also important. A large number of additional questions before work can begin may indicate that the form and required information should be structured first.
Common processes should also be separated from specialist processes. ESM does not mean that every departmental system becomes unnecessary. A service platform may take over the layer of receiving and coordinating requests, while the actual execution still takes place in a specialist application.
Criteria for evaluating the impact of the change should also be defined. This may include better status visibility, fewer manual handovers, shorter waiting time for approval, or more consistent communication. Without such a reference point, it is easy to assess the project only by whether the system has been launched.
In Mint Service Desk, ESM can be built as an extension of a structured service model
In this context, Mint Service Desk can act as a shared environment for handling selected service processes outside IT. Instead of creating a separate request intake mechanism for every department, requests can be organized through queues, types, statuses, and defined processes, while maintaining a clear handling history.
The most important element is the shared working model. HR does not have to work in the same way as IT, and administration does not have to copy the procurement process. Individual teams can keep their own rules while working in an environment where responsibility handovers and request statuses are easier to control.
ESM implementation should not, however, start with an attempt to move every process into the system. A more reasonable approach is to select a few well-understood services, define their flow, and then gradually expand the scope in areas where a shared model brings real operational value. Available deployment and pricing options can be reviewed on the Mint Service Desk pricing page.
ESM makes sense when the organization wants to manage a service, not only pass tasks around
Not every company using ITSM needs ESM. For simple, local, and well-controlled processes outside IT, an additional management layer may not bring real value.
The signal for change is a repeated pattern: similar types of requests in many departments, no shared status, manual handovers, processes passing through several teams, and new tools created only to maintain order in a local fragment of work.
In this case, the ITSM vs ESM question is not about which abbreviation is more current. It is about whether the organization wants to continue managing separate inboxes of tasks, or begin managing services from beginning to end.
The quality of a process is not determined by the number of automations. What matters more is whether it is clear what should happen next, without reconstructing that knowledge from several people’s memory.
