The real test of a quality system isn’t what happens when everything works. It’s what happens when something doesn’t.

Recently, two of my cameras failed. They were newer versions of models whose older predecessors still worked, so I contacted the manufacturer to report the problem.

I expected a warranty conversation. Instead, the company asked me to return the failed cameras so it could identify the defects. They asked questions about the circumstances of the failures because they wanted to understand what had happened. They told me they would send replacements. They even offered a discount toward another product I might want to purchase.

There was no blame. The failed cameras were treated as more than defective products; they were sources of information.

That experience brought back a thought I first encountered more than three decades ago. In 1989, I read Christopher Hart’s The Power of Unconditional Service Guarantees (Harvard Business Review, July 1, 1988). I found the idea intriguing: Remove much of the customer’s perceived risk by making a strong promise and accepting responsibility when the promised experience isn’t delivered.

At the time, I considered the idea primarily from a customer-service perspective. Today, I see another question: What if we really owned the customer’s outcome? What would that do to the way we design, operate, measure, and improve our quality systems?

Two very different responses to failure

Not long after my camera experience, I encountered a very different response to a system failure—this time, with an installer we had trusted for five years.

Back then, we had solar panels installed on our roof. Before the installation, the contractor conducted an analysis of the roof’s condition, determined that it was suitable for the installation, and assured us of many years of trouble-free service—at least 15 years. The system performed as expected for half a decade until the most recent rainy season, when our roof began to leak.

We contacted the contractor. An inspector examined the roof and the installation, only to conclude that the roof was now in poor condition and that the company couldn’t address the problem because the solar panels and their installation were fine.

We showed them the original assessment indicating that the roof had been evaluated and considered suitable for the installation.

The discussion that followed quickly pivoted away from solving the problem and focused on establishing responsibility:
• Was the problem with the roof?
• Was it with the installation?
• Was it something that existed before the solar panels were installed?

Those are legitimate questions. Determining technical and contractual responsibility matters. But from a quality management perspective, another question is more interesting: What happens to an organization when the customer’s expected outcome fails to occur?

Compare that experience with the camera manufacturer. The cameras failed, and the manufacturer’s response was essentially: Let’s get the failed products back and understand what happened.

The roof leaked, and the response became: Let’s determine where responsibility lies.

I’m not suggesting that one organization is good and the other is bad, nor that these two experiences are enough to determine technical responsibility. What interests me is the difference in organizational behavior when a system fails.

Failure: Problem or information?

Every failure creates at least two possibilities. It can become a problem to be resolved, or it can become information to be learned from.

Of course, a good organization must resolve the immediate problem. Customers can’t wait for a lengthy root-cause investigation before receiving help. But the best response can do both: Recover the customer and learn from the failure.

That’s what made the camera experience stand out. The manufacturer didn’t just log a claim. It wanted the failed products back.

Why? Because that physical evidence could help shorten the path to understanding what went wrong. The customer experiences the symptom, but the returned hardware could contain evidence of the cause. Bringing that evidence back into the engineering loop closes an important gap between field performance and design feedback.

Consider the difference between two approaches.

The first is a linear administrative path:
Customer/complaint/determine coverage/replace/close

The second creates a closed-loop learning system:
Customer/failure/recovery evidence/investigation/learning/improvement

The difference isn’t merely procedural but reflective of a fundamentally different way of thinking about quality.

The warranty as a feedback mechanism

We often think of a warranty as a promise made to protect the customer. But perhaps it can serve another purpose: a feedback mechanism for the quality system.

Every failure experienced by a customer tells us that something didn’t produce the expected result. The important question isn’t simply, “How many warranty claims did we have?” Rather, it’s, “What is the system telling us through those claims?”

A failed product can reveal weaknesses in design, materials, suppliers, manufacturing, installation, instructions, maintenance, or even our understanding of the customer’s requirements. A customer complaint can therefore be more than an unhappy customer’s voice. It can be a signal from a process.

This is familiar territory for quality professionals. We already talk about feedback, root-cause analysis, corrective action, prevention, and continual improvement. The difference is that a strong commitment to the customer’s outcome can make that feedback much more consequential.

If the organization has said, in effect, “If you don’t get the expected outcome, we will make it right,” then failure is no longer something that can easily be passed along to the customer. It becomes the organization’s problem to understand. And that changes the question from, “Who’s responsible? to, “What do we need to learn?”

The challenge behind the promise

An unconditional guarantee sounds like something that matters after a failure. Its greater impact, however, may be what it changes before the failure occurs. If we were willing to tell a customer, “If you don’t get the expected outcome, we will make it right,” we would create a powerful design constraint for the organization.

We would have to ask:
• Do we really understand what the customer expects?
• What can go wrong?
• Where are the likely failure modes?
• How will we detect problems before they reach the customer?
• What interactions exist between our product and the customer’s existing system?
• Who has the authority to act when something does go wrong?
• What will we do with what we learn?

The guarantee therefore becomes more than a promise. It becomes a challenge to the system. The organization isn’t simply being asked to produce a product or deliver a service. It’s being challenged to consistently produce the outcome the customer values.

That’s a very different definition of quality.

Resolving the system contradiction

This creates a classic organizational dilemma—what TRIZ practitioners recognize as a system contradiction. We want to increase customer peace of mind by removing risk from the customer. At the same time, doing so appears to increase warranty exposure and financial risk for the company.

Often, the conventional management response is to compromise. Organizations protect themselves by adding conditions, fine-print exclusions, and strict boundaries to limit exposure. They trade some customer trust for greater control over financial risk.

TRIZ thinking (the theory of inventive problem-solving) challenges us to ask a different question: What would have to be true for us to offer an unconditional guarantee while rarely having to invoke it?

That question takes us upstream. Instead of focusing primarily on the cost of claims after something goes wrong, we begin looking at product design, process capability, robust installation checks, early detection, and rapid learning loops.

The goal isn’t to become exceptionally good at processing claims. The goal is to eliminate the source of the conflict by creating a system so reliable that the guarantee becomes inexpensive to honor because failures are extraordinarily rare.

The guarantee isn’t the solution. The system that makes the guarantee sustainable is the solution.

A guarantee is a promise; the response reveals the culture

This brings us back to the two experiences.

The camera manufacturer didn’t need to tell me that it had a sophisticated quality culture. Its behavior communicated it. It accepted the customer’s experience, provided immediate recovery, requested the failed product, asked diagnostic questions, and focused on learning.

The solar experience produced a very different interaction—one where failure immediately shifted the focus toward contract boundaries and liability.

Again, the point isn’t to decide which organization was technically or contractually correct. The point is to recognize that the response to failure reveals how an organization thinks about quality. Does it primarily ask, “How do we protect ourselves from this failure?” Or does it ask, “How do we understand this failure and prevent it from happening again?”

Those questions can lead an organization in very different directions.

What if we really owned the customer’s outcome?

Perhaps this is the more useful way to think about an unconditional guarantee: Don’t begin with the wording of the guarantee. Begin with the system behind it.

Imagine sitting with your leadership team and saying, “Suppose we couldn’t hide behind the fine print. Suppose we had to own the customer’s outcome. What would we have to change?” That question could expose weaknesses that ordinary quality metrics sometimes don’t:
• Would we need to change how we design products?
• How do we select and manage suppliers?
• How do we validate installations?
• How quickly do we respond to failures?
• How much authority do employees have to make things right?
• How do we capture and analyze field information?
• How do we close the loop between customer experience and product or process improvement?

The commitment reaches far beyond customer service. It influences product and process design, supplier relationships, installation protocols, employee authority, and the rigor of failure investigations. Most important, it forces management to confront a fundamental question: How confident are we that our system will consistently deliver what the customer values?

Perhaps the most powerful guarantee isn’t the one with the most generous language. It’s the one supported by a system so capable that the guarantee rarely needs to be invoked.

A guarantee is a promise made to the customer. But its ultimate value may be the challenge it creates for the organization. If we’re willing to own the customer’s outcome, are we willing to design the system so that we can consistently deliver it?