What an ESM framework is, and why it stalls

Enterprise service management is one of those terms that sounds like a bigger version of ITSM, and is often sold that way. The idea underneath it is genuinely good. The reason so many ESM efforts stall before they deliver on it is worth understanding, because it is almost never about the framework itself.

ESM in one sentence

Enterprise service management is taking the disciplines that made IT service management work, structured request intake, a service catalogue, defined workflows, knowledge, and clear ownership, and applying them to every department that delivers services internally. HR, facilities, finance, legal, procurement. Anywhere people request something from a team and wait for it to be done.

The promise is that an employee should be able to ask for a new laptop, a contract review, a desk move, or a reference letter through one consistent experience, instead of learning a different process and a different inbox for every department.

The framework

An ESM framework is not complicated in principle. It generalises the ITSM building blocks so they are not IT-specific:

• A single intake where any request, to any department, can be raised the same way.
• A service catalogue that lists what each department offers, so requests are structured rather than free-text guesses.
• Workflows and approvals defined per service, so each request follows a known path.
• Knowledge so common questions are answered without a request at all.
• Ownership and reporting so every team can see its own queue, load, and performance.

On paper this is straightforward, and most ESM frameworks describe roughly this. The hard part is not the design.

Why ESM usually stalls at IT

Here is the pattern. IT does service management well, decides to extend it to the rest of the business, and runs into a wall the framework did not warn them about: every other department already has its own tools and its own way of working. HR is in one system, facilities in another, legal in a shared mailbox.

So extending ESM means either forcing every department onto the IT service platform, which they resist because it was built for IT and feels like it, or integrating a dozen separate tools, which is expensive and fragile. Both routes are heavy enough that most organisations quietly stop at "IT has good service management, and everyone else does their own thing." The framework was fine. The rollout died on the cost of crossing departmental tool boundaries.

What actually makes ESM spread

ESM spreads when adopting it does not require each department to move to a new, foreign platform. The frameworks miss this because they assume a service platform and treat where it runs as a detail. In ESM, where it runs is the whole game. A service experience only becomes shared if it lives somewhere every department already is.

ESM in Microsoft 365

This is where running service management natively in Microsoft 365 changes the game, as Microsoft is the joined denominator across departments. Every department, IT or not, already lives in Teams, Outlook, and SharePoint. When the service framework runs there, extending it to HR or facilities is not a migration to an IT tool. It is turning on structured intake, catalogue, and workflow in an environment those teams already use every day.

Why this removes the barrier

The intake is in Teams, where people already are. The data stays in the organisation's own tenant, under one set of governance and identity controls, which matters as soon as HR and legal data is involved. No department is asked to adopt a platform that was obviously built for someone else.

That is why ESM so often stalls at IT in a traditional setup, and why it tends to keep moving in a Microsoft-native one. The framework was never the obstacle. The obstacle was asking every department to leave where it works. Remove that, and enterprise service management can finally be enterprise-wide.

The bottom line

ESM frameworks fail less often on design than on distribution. Asking every department to adopt an unfamiliar IT-built platform is where most efforts quietly stop.

Running service management inside Microsoft 365 sidesteps that cost. Every department is already there, so extending structured intake, a catalogue, and workflows is a configuration step, not a migration.