Making the hidden work inside services visible

In Part I, we introduced the idea of service burden — the total effort required for a service to function.

Some of that effort sits inside the organization.
Some of it lands on employees.
Some of it lands on the person trying to use the service.

The burden never disappears. It simply moves.

The challenge for most organizations is that this movement is rarely examined deliberately. It happens gradually, through dozens of operational, product, and compliance decisions made over time.

To understand where the work of a service actually lives, it helps to make it explicit.

One way to do that is through a simple analytical tool: the Service Burden Canvas.

The Service Burden Canvas

The canvas maps where effort sits across a service system and how it has shifted over time.

Dimension	What it examines	Key question
User Burden	The effort required from the person trying to use the service	What work must the user do to complete the task?
Operational Burden	The internal processes required to run the service	What work happens behind the scenes to keep the service functioning?
Employee Burden	The effort absorbed by frontline teams and operational staff	Where are employees compensating for gaps or friction in the system?
Technological Burden	The complexity of the technology stack supporting the service	How much effort is required to maintain, integrate, or troubleshoot the technology behind the service?
Burden Migration	How effort has shifted across the system over time	Compared to earlier versions of the service, where has the work moved?
Industry Benchmark	How other organizations solve similar problems	How have leading companies redistributed or reduced similar burdens?
Innovation Opportunity	Where improvements could meaningfully reduce effort	Where could design or technology remove unnecessary work from the system?

The goal of the canvas is not to eliminate burden entirely.

Every service requires effort somewhere.

The goal is to understand where that effort sits — and whether the balance still makes sense.

Applying the Canvas: Maria and Deepak

Returning to the insurance example from Part I, the burden becomes clearer when mapped explicitly.

Dimension	Analysis
User Burden	Maria must take and resize photos, locate documentation she may not have, interpret unclear submission requirements, and spend significant time waiting on support before she can even begin the claims process.
Operational Burden	Fraud detection reporting only provides high-level metrics, requiring Deepak’s team to manually analyze claim patterns and repeatedly adjust verification rules across multiple internal systems.
Employee Burden	Customer support agents spend a growing share of their time explaining submission requirements and helping users restart failed claims instead of resolving the claims themselves.
Technological Burden	The claims platform relies on several disconnected systems for document uploads, fraud detection, and policy validation, creating fragile workflows that frequently fail during normal use.
Burden Migration	When Maria originally signed up for her policy, claims could be initiated by phone with an agent guiding the process. Over time, the company shifted toward a digital-first claims portal, moving much of the submission effort onto the customer.
Industry Benchmark	Several insurers now use automated image validation and guided claim workflows that confirm photo quality and documentation in real time, reducing both fraud risk and customer confusion.
Innovation Opportunity	Structured claim workflows and automated fraud detection could reduce blanket verification steps, allowing the risk team to focus on genuinely suspicious claims while simplifying the process for legitimate customers.

Looking at the system this way produces a very different kind of insight.

Instead of asking “How do we build a better claims portal?”, the organization can ask:

Where is the work of the claims process currently accumulating?

The answer often points directly toward meaningful improvements.

What the Canvas Reveals

In many organizations, mapping service burden reveals patterns that were previously invisible. Support teams absorbing large volumes of confusion on how to do things often indicate friction created earlier in the product experience.

Operational teams performing repeated manual analysis often signal gaps in internal tooling or reporting.Users performing complex multi-step tasks frequently reveal workflows optimized around internal systems rather than real-world behavior.

Seen this way, service burden becomes less of a complaint and more of a diagnostic tool. It highlights where effort has accumulated and where innovation might actually matter.

What Changes When the Burden Changes

One way to test whether service burden is a useful lens is to look at moments when a service noticeably improves.

The explanation often focuses on technology: a faster platform, a cleaner interface, a new automation layer.

But sometimes the more meaningful change happens elsewhere — in how the work of the service is distributed.

Consider Amazon’s approach to customer service.

In the early 2000s, most large companies ran support operations through strict escalation hierarchies. A typical issue moved through several layers: first-line support, specialist teams, and often a supervisor before anything meaningful could be resolved. The structure reduced internal risk, but it required customers to carry much of the burden of navigating the system — repeating their issue, waiting for callbacks, or figuring out which department might actually help.

Amazon reorganized the service differently. Support agents were given unusually broad authority to resolve problems during the first interaction. If a package was lost, they could send a replacement immediately. If an item arrived damaged, they could issue a refund. Escalation was still possible, but it was no longer the default path.

This did not eliminate effort from the system. In many ways it increased the operational responsibility inside Amazon. Agents needed better training, clearer policies, and the discretion to make decisions that other companies would route through multiple layers of approval.

But the burden inside the service had been redistributed.

Customers no longer had to navigate the organization to get a resolution. Support agents were not limited to acting as message passers between departments. The system was designed so that problems could be solved where they appeared.

The result was not simply faster customer service. It was a service that required less effort from the people using it.

Seen through the lens of service burden, the interesting shift was not technological. It was structural.

The Modern Service

In Part I, we began with a simple observation:

Despite years of digital transformation, a surprising number of modern services still feel strangely difficult to use.Technology has improved dramatically. Interfaces are more polished. Systems are faster. Yet the underlying experience often remains frustrating.

Part of the reason may be that many organizations focus primarily on adding capabilities — new features, new platforms, new automation — without examining how the structure of the service itself has evolved.

Every service requires work to function. The real question is who ends up doing it.

Understanding service burden does not solve every problem in service design. But it offers a way of looking at services that cuts through much of the noise around innovation.

It forces organizations to ask a more grounded set of questions.

Where is effort accumulating? Who is carrying it? And does the current balance still make sense?

If modern services are meant to be improvements on the systems that came before them, then answering those questions may be just as important as the technologies used to build them.