Working services that aren't, and why they keep failing the people who use and deliver them

Most organisations don't know what's really happening in their own delivery, what it's costing them, or where to start fixing it

There's a pattern I've seen repeat itself across large organisations, government and health services — workarounds, integration failures and broken handoffs. These are well known to frontline staff and service users, but remain hidden, undocumented and unresolved. Not because no one cares, but because business-led process maps imply everything is fine.

The reason this happens is usually the same. A business-led approach starts by defining what should happen, then that definition becomes the reality, on paper at least. A service-led approach does the opposite: it maps out what actually happens first across the full end-to-end journey before making any recommendations. That distinction sounds simple. But it changes everything about what you find, what you understand as the biggest issues, and what you're able to fix.

This usually only surfaces when you research the full service journey from both staff and user perspectives. That's when teams start to realise the system was never quite what anyone thought it was. The business-led process map said one thing. The lived reality was something else entirely.

The problem

In my experience, it usually comes down to three things.

Intended states get mistaken for actual ones. When a service blueprint or business process is documented, it represents how someone thinks the service should work, or hopes it will. But it gets treated as a description of how the service ‘actually’ works. Every gap between the map and reality is a risk that isn't being managed.

Processes get mapped in pieces, not as a whole. Business processes are often documented in discrete sections rather than as a connected end-to-end journey. Every integration point and handover between those sections becomes a blind spot and a potential failure point. This is especially common where a journey crosses organisational boundaries, for example, where ownership moves from a digital team to a specialist operational team. Nobody mapped the join, so nobody owns the gap.

Purpose gets lost along the way. Over time, organisations become so focused on the internal processes that they lose sight of why those processes exist. Success gets measured by whether you did what you said you'd do, rather than whether it made any difference to the people you were supposed to be serving. When that happens, improvement becomes almost impossible because there's no longer a shared sense of what you're trying to improve toward.

The impact

False sense of control. Documentation such as blueprints, process maps, and architecture diagrams is often treated as evidence that things are under control. But if the documentation doesn't reflect reality, it's doing the opposite: hiding risk behind a veneer of orderly process. The more polished the artefacts, and the more they're accepted as truth, the harder it becomes to see what's actually going wrong, or make a case for investigating further.

The burden of resolution falls on operational staff. Frontline staff live the reality gap every day. Sandwiched between what the organisation believes and what they know to be true, they resolve issues as best they can, with ad hoc fixes, manual processes and workarounds that remain largely invisible to central teams and leadership. Workarounds multiply, and complexity increases. The official picture stays clean while the actual service deteriorates — often with the very people holding it together blamed for breaking the processes designed centrally.

Digital products get elevated above the services they sit within. All large organisations today have digital products and technology platforms embedded within their service delivery. Too often, these are treated as separate entities, evaluated on their own metrics, run by their own teams, optimised against their own definition of success. A digital product is generally a touchpoint within a wider end-to-end journey, or a platform that underlies it. Either way, product and platform performance only make sense in the context of the full service offering. When product teams are scoped, mapped, and measured independently, you get well-functioning products sitting inside failing services, with no one with the mandate to see the connection.

Process gets prioritised over outcomes. Every proposal for change gets evaluated against existing processes and committed outputs rather than against what the service is actually supposed to achieve. Over time, this becomes a barrier to genuine improvement, effort gets scoped within a fixed frame. Issues remain hidden and unresolved, and the gap between intended and actual state quietly widens. The result is an organisation that is very good at creating good news stories for management, while the real problems go unaddressed.

What needs to change?

The alternative starts with being honest about what you don't know. Rather than documenting an intended state and calling it a service, the more useful starting point is to map what actually happens from the perspective of the person trying to use the service, not the organisation trying to deliver it. A user-centred system map does this; it shows the full journey, including the gaps, handoffs, and moments when the service assumes the user will do something they may not. It makes the unknowns and issues visible rather than hiding them in a tidy diagram that obscures risk but tells a good news story.

This matters beyond service design practice. The gap between what a service is designed to do and what it actually delivers has real consequences for the people who fall through it, and for the strategic intent it was supposed to serve. This is especially true for organisations whose service delivery spans digital and physical channels. For example, where individual product teams might own parts of the journey and operational teams own the others. Without a unified view of the end-to-end, each part gets optimised separately while the joins between them quietly fail.

A service-led approach gives organisations a shared mental model: a common understanding of how the whole thing works, what success actually looks like, and where the real priorities are.

I've spent a lot of time in recent years working across complex organisations in the private sector, health, government and welfare, investigating where services fail to reach the people they're meant to serve. Across both my research and my practice, the pattern is almost always the same: not a failure of intent, but a failure to honestly account for the distance between intention and reality. Getting that distance right is where the work actually begins.

How does this play out in your own organisation? I'd be interested to hear where you've seen this pattern, and what it took to make it change.

——

This connects to a broader pattern I've written about elsewhere. Check out, How to understand ‘services’ as a tool for your whole organisation, How to define ‘service’ and Design bias in service blueprints.