We Don’t Need Another Service Desk—So Why Do We Keep Building Them?

Most large organizations have one: a support ecosystem that grew faster than it was designed. Getting help feels harder than it should. People spend more time navigating systems than solving problems.

This is not an unsolvable problem. More often, it is an unasked question—and one I have been thinking about for a long time.

I’ve spent more than 20 years in IT operations. I’ve built large contact centres and managed service environments supporting tens of thousands of users, and I’ve watched organizations evolve over time. I could see where things were heading. Every new service brought its own support model. Each decision made sense in the moment. But the pattern was unmistakable: we were building layers when we should have been building connections. The idea was there. The conditions were not.

More recently, I was asked to help reduce service desk sprawl in a large enterprise environment. What I found wasn’t dysfunction. Teams were doing exactly what they had been asked to do. But none of it added up to a single, coherent experience. Users were paying the price, and the organization was leaving real capability on the table.

Requests disappeared into different systems. Patterns stayed hidden. Data that could support automation remained disconnected. And the lack of integration limited more than efficiency. It reduced our ability to prevent issues, improve self-service, and prepare for what more intelligent support models could make possible.

That is where the question has to change—from “How do we improve each service channel?” to “What would it take for this to feel like one service?”

That is the design challenge worth paying attention to: clear access, coordinated support, and a stronger foundation for automation and continuous improvement—instead of patching the same problems in slightly different forms, over and over.

We have the tools. We have the data. We have teams that want to do this well.

What we need is the will to stop building around the problem—and start redesigning the system that keeps recreating it.

That work is happening. And it is worth your attention.