During a recent visit to a brewery in Dublin, I was stopped by one statement displayed on the tour: “The quality of our advertising must be equal to the quality of our beer.”

It was intended as branding. But it pointed to something most organizations quietly overlook: They assume quality begins when production begins.

That assumption is wrong.

In most systems, the most expensive defects are created before anything is produced; they’re created when a promise is made. And once made, that promise becomes the system constraint to which everything else must adapt.

Most quality problems start before we look

After more than three decades working in quality systems, I’ve become convinced of something simple: We define the system too late.

We’re very good at controlling what happens after requirements are fixed—manufacturing, delivery, service recovery, corrective action.

But by then, the system has already committed to something. The more important question isn’t whether we delivered correctly. It’s whether we should have made that promise in the first place. Customers don’t experience our functions. They experience a single flow:

Promise → expectation → delivery → judgment

That chain is usually shaped long before production begins.

When the system fails before it starts (an SaaS pattern)

A familiar version of this shows up in software as a service (SaaS) environments. A platform is sold on a clear, compelling narrative: rapid deployment, seamless integration, unified data, a “single source of truth.”

The demonstrations are real. The features exist. The capability isn’t imaginary. But what’s often not carried forward with equal weight is what it takes for that capability to behave as promised:
• Integration effort
• Data cleanup
• Process redesign
• Governance discipline
• User adoption

All real. All necessary. All frequently underemphasized in the initial promise. The organization buys the promise, not the system. And when implementation begins, reality does what it always does.

It asserts itself.

What looked like out-of-the-box simplicity becomes months of integration work, workflow redesign, and internal negotiation. Internally, the conclusion is often, “The system is fine. It just doesn’t do what we thought it would.”

From a quality perspective, nothing failed.

From a customer perspective, everything did.

The same pattern in physical systems

This isn’t a software issue. It’s a promise issue.

In one industrial automation case, a high-performance actuator was deployed in demanding environments where temperature resilience was part of the value proposition. The product itself was capable—but only under a specific condition. Auxiliary cooling was required to maintain full-rated performance at higher temperatures.

That condition was real, known, and tested. But it wasn’t part of the customer’s mental model of what had been promised, and installations went ahead without it. Performance dropped. Throughput fell. Escalations followed.

Inside the company, the conclusion was straightforward: The product met specification. Outside the company, the conclusion was equally straightforward: The product failed.

Both were correct. Only one determined the relevant outcome.

The structural problem isn’t technical

Most organizations describe this as a handoff problem:
• Marketing oversells
• Sales simplifies
• Operations execute
• Quality fixes

But that explanation is incomplete. Each function is behaving rationally inside its own incentives. The issue is that no one owns the integrity of the promise as it moves across those boundaries. The system optimizes locally and fails globally. The failure shows up later as: 
• Returns
• Escalations
• Rework
• “Customer expectation issues”

By then, the system has already delivered exactly what it committed to—whether that commitment was realistic or not.

Deming’s point, restated simply

W. Edwards Deming made this observation repeatedly: “The customer experiences the system, not its parts.”

Outside the company, there’s no marketing, sales, operations, or quality. There’s only one question: “Did you deliver what you led me to believe you would deliver?”

That question is formed before delivery begins. Not after.

A different kind of defect

Traditional quality systems are designed to detect physical defects: 
• Wrong dimension
• Wrong material
• Wrong performance

But some of the most expensive defects never appear in production data. They appear earlier, when the promise exceeds what the system can reliably deliver under real operating conditions, or when critical constraints are left implicit.

These defects don’t create scrap. They create disappointment, and that’s expensive in a different way. It’s not visible in inspection records. But it’s very visible in customer behavior.

Beyond the factory gate

For decades, quality has focused on improving execution:
• Reducing variation
• Stabilizing processes
• Preventing defects

That work is still necessary, but it’s not sufficient. Because in many organizations, the system that determines customer satisfaction begins before production—and is still outside the discipline of quality. That system is the promise-making system. It’s usually optimized for persuasion, not consistency.

Conclusion: Where the system actually begins

Quality doesn’t begin at production, and it doesn’t end at delivery. It begins when a promise is made—and it ends when that promise is either confirmed or broken.

Everything in between is execution.

If quality is a systems discipline—as Deming and Eliyahu M. Goldratt would both recognize—then we can’t define the system boundary where it’s convenient.

The factory gate was never the start of quality. It was only where we started measuring it.