Nobody in Human Resources (HR) comes to work hoping IT will introduce them to Enterprise Service Management (ESM). Facilities is not waiting for a service catalog presentation, and Legal probably has no interest in joining a workshop about workflows. These teams are dealing with lost requests, delayed approvals, confused ownership, and employees who can’t get a straight answer about what is happening. Service management may help with all of that. In many cases, it probably will. But calling it Enterprise Service Management too early can turn a useful idea into another IT program that the rest of the business feels it is being asked to adopt.
So my advice is simple: never suggest ESM.
That doesn’t mean we should keep what we know to ourselves. IT teams have spent years learning how to organize requests, define ownership, manage knowledge, improve handoffs, and measure whether services are working. These practices can be valuable far beyond IT. The mistake is assuming that other departments need the concept before they can benefit from its ideas.
We tend to start with the answer – ESM
IT people like naming things. We find a set of useful practices, organize them into a framework, give the framework an acronym, and then become surprised when nobody outside IT is especially excited about it.
Take a look at how IT usually reacts to other teams’ pain points. Facilities gets bombarded by hallway conversations and emails, so we immediately pitch a service catalog. HR spends days chasing five departments to prepare for a hire, so we jump straight to automated onboarding workflows. Finance tracks approvals in spreadsheets, and we’re already picturing them inside our IT service management (ITSM) tool. We jump straight to the technical setup before they’ve even finished explaining the headache.
We may be completely right about the solution. The problem is that we have skipped ahead.
The other department is still thinking about missing information, frustrated employees, and work that keeps getting stuck. We are already talking about ESM, ITIL practices, portals, and implementation. A conversation about solving a departmental problem has quietly become a conversation about joining an IT initiative.
Once that happens, resistance is almost inevitable. People begin wondering how much control they will lose, how much extra process they will inherit, and whether IT is about to redesign work it does not fully understand.
Help people examine the work
A better approach is to slow down and help the team understand how the work actually happens.
Take employee onboarding. Instead of presenting an ESM workflow, start by tracing the process with HR. Look at where the request begins, what information is usually missing, which handoffs create delays, and how anyone knows whether everything is ready before the employee arrives. Follow the work far enough, and the team will usually discover its own requirements.
Perhaps HR needs a consistent way to begin the process. Maybe tasks need clear owners, automatic reminders, and a shared view of progress. The department may want fewer emails, better visibility, or a simple way to identify why onboarding repeatedly falls behind.
At that point, service management practices may become useful. The important difference is that the team reached the need by examining its own work. Nobody had to convince HR to care about ESM. HR already cared about fixing onboarding.
This is what coaching should look like. We can ask questions, share patterns we have seen elsewhere, and explain which practices have helped IT solve similar problems. We should also be prepared for the department to reject parts of our approach. A process designed for the IT service desk may be too rigid, too detailed, or simply irrelevant in another context.
That is fine. The objective is to improve the service, not to reproduce IT’s operating model in every department.
Let the department shape the solution
One reason ESM initiatives struggle is that IT often retains too much ownership. We schedule the meetings, document the process, configure the platform, create the reports, and keep reminding everyone why the project matters. The initiative can look successful, but only because IT is constantly pushing it forward.
When the team becomes busy with something else, the momentum disappears. Requests drift back into email, people stop using the workflow, and the project slowly becomes another thing everyone agrees was a good idea.
Real adoption looks different
The department defines the outcome, decides how the process should work, and notices when it stops working. Let the teams take ownership of their own rules. HR gets to choose terms their people actually use, Facilities determines what intake info is required, and Legal can throw out approval steps that sound good on paper but stall real work.
IT still has an important role. We can help the team avoid common mistakes, introduce useful practices, and make sure the solution does not become a new collection of disconnected tools and manual workarounds. But the department needs enough ownership to care about the result without IT continually supplying the energy.
When an initiative only moves forward because IT is forcing it, that is not true adoption.
Start with something small enough to work
None of this requires a company-wide transformation. In fact, announcing a large ESM program may be the fastest way to make the work slower, more political, and less connected to the original problem.
Start with one issue that people already want to solve. It should be painful enough to matter and contained enough that the organization can improve it without creating a governance structure around it.
Maybe maintenance requests are being lost. Perhaps new employees arrive without the access or equipment they need. Maybe contract approvals sit in an inbox for days because nobody knows who is supposed to act next.
In practice, the approach is straightforward
Find a problem the department already wants to solve, trace how the work currently moves, and help the people involved define a better outcome. Introduce service management practices only when they support that outcome; let the department make the important design decisions; and measure whether the change reduced delays, missing work, or manual follow-up. If it worked, let that result create the demand for whatever comes next.
A useful result creates its own demand. People begin asking whether the same approach could help with another process or another team. Service management is spreading because departments are pulling useful practices toward themselves, rather than because IT is pushing a concept across the organization.
That is also where stickiness comes from. ESM becomes sustainable when the people using the process want to keep improving it, even when IT is no longer standing beside them.
Maybe ESM caught on without the name
People sometimes ask why ESM “never really caught on.” We may be looking for the wrong signs.
Every time HR improves onboarding with clearer ownership and better handoffs, or Facilities creates a reliable way to receive and track requests, service management thinking may already be present. The department may never use the term ESM, and that should not bother us.
The point is to help the organization deliver better services. Whether everyone uses our preferred vocabulary is far less important.
So do not begin by selling the concept. Help people understand their work, share what IT has learned, and let each department decide which practices fit. When the solution feels like something they discovered and helped create, we will not need to keep convincing them that it matters.
InvGate’s free Enterprise Service Management course on Udemy explores how to take this approach in practice: thinking big, starting with manageable problems, and applying service management beyond IT without forcing every department into the same model.
ESM FAQs
Matt Beran argues IT teams should stop pitching Enterprise Service Management by name to other departments. Instead of leading with the framework and the acronym, IT should help a department solve its actual problem first, and let service management practices show up as the answer, not the pitch.
Because it turns a conversation about solving a department’s real problem into a conversation about joining an IT initiative. Once that shift happens, people start worrying about losing control, inheriting extra process, or having IT redesign work it doesn’t fully understand, and resistance follows.
Trace how the work actually happens with the department first. For onboarding, that means looking at where a request begins, what information usually goes missing, which handoffs cause delays, and how anyone knows the work is ready. The department usually surfaces its own requirements once it sees this clearly.
The department. Matt Beran argues that ESM efforts stall when IT keeps “holding the pen,” scheduling meetings, documenting the process, and keeping the project moving. Real adoption happens when the department defines the outcome, sets its own rules, and notices when the process stops working.
Small. Matt Beran recommends starting with one contained, already-painful problem, like lost maintenance requests or slow contract approvals, rather than a company-wide rollout, since a large program tends to make the work slower and more political.
No. Matt Beran’s view is that service management thinking is present any time a department improves ownership, handoffs, or visibility, whether or not anyone ever calls it ESM. The goal is better service delivery, not adoption of IT’s vocabulary.
Coaching. IT can ask questions, share patterns from similar problems it’s solved before, and help the department avoid common mistakes, while accepting that a process built for the IT service desk might be too rigid or irrelevant elsewhere.
Matt Beran
Matt Beran is an IT Industry Analyst and Expert who is currently the Product Marketing Specialist at InvGate. He also hosts the extremely popular Ticket Volume Podcast.
