Critical to Quality, usually abbreviated CTQ, describes the measurable characteristics that are essential to meeting a customer need.

Customers often express needs in broad language: fast delivery, easy setup, reliable operation, accurate invoices, quiet equipment, or good service.

Those statements are important, but they are not yet operational requirements.

A CTQ translates the need into something the process can measure and control.

From customer language to process language

Suppose a customer says, “I need fast delivery.”

That statement must be translated into a measurable requirement.

A CTQ might become:

“95 percent of standard orders ship within 24 hours of order confirmation.”

Now the organization can define data, measure performance, analyze causes of failure, and design controls.

The CTQ connects customer value to process performance.

The CTQ translation chain

A useful way to think about CTQs is:

customer need → driver → measurable requirement.

For example:

Need: easy to install.

Driver: installation time.

CTQ: 90 percent of standard installations completed in less than 20 minutes without specialized tools.

The stronger the translation, the easier it becomes to design or improve the process.

CTQ is not simply any KPI

A process can have many measures. Not all of them are CTQs.

A CTQ should have a meaningful connection to what the customer values or requires.

Machine utilization, meeting attendance, or number of reports issued may matter internally, but they are not automatically CTQs.

The question is: does this characteristic materially affect the customer’s definition of acceptable performance?

Sources of CTQ requirements

CTQs can be developed from multiple sources:

  • customer interviews;
  • complaints and returns;
  • surveys;
  • specifications;
  • contracts;
  • regulatory requirements;
  • warranty data;
  • service records;
  • direct observation of customer use;
  • Voice of Customer analysis.

Different customer segments may have different CTQs, so teams should avoid assuming that one requirement fits everyone.

Making CTQs measurable

A useful CTQ should define what is measured, the unit, the target or specification, and the conditions under which the requirement applies.

Compare:

“Orders should be accurate.”

with:

“Order line accuracy ≥ 99.5 percent per month.”

The second statement creates a clear operational requirement.

CTQ trees

A CTQ tree is one method for breaking a broad customer need into more specific drivers and measurable requirements.

For example:

Need: dependable service.

Drivers: on-time response, first-time resolution, clear communication.

Possible CTQs:

  • initial response within 30 minutes;
  • 90 percent first-time resolution;
  • status updates at agreed intervals.

The tree helps teams avoid jumping directly from a vague need to an arbitrary metric.

Common mistakes

One mistake is defining CTQs entirely from internal opinion without obtaining actual customer evidence.

Another is choosing measures because they are easy to collect rather than because they represent customer requirements.

A third is creating CTQs that are too broad to control. “High quality” is not measurable enough.

A fourth is setting a specification without understanding the process capability required to achieve it.

CTQ and process improvement

CTQs help improvement teams decide what outcomes matter.

In DMAIC, they can guide problem definition, measurement planning, capability analysis, improvement priorities, and control plans.

In product or process design, they help translate customer expectations into engineering or operating requirements.

The practical test

A strong CTQ should pass three tests:

Is it connected to a real customer need?

Can it be measured consistently?

Can the process reasonably influence it?

If the answer to all three is yes, the CTQ becomes a powerful bridge between customer value and operational control.