CTQ stands for Critical to Quality — the specific, measurable customer requirements a product or service must meet. Also called Critical to Customer, CTQs translate broad customer needs (“fast delivery”) into precise specs (“shipped within 24 hours, 99% of the time”) that Six Sigma teams can improve.
Identifying Critical to Quality (CTQ) attributes helps align business operations with customer expectations, enhancing satisfaction and loyalty. Methods like customer feedback, competitor analysis, and quality function deployment can pinpoint these key attributes.
What Does CTQ Stand For?
CTQ stands for Critical to Quality. The term refers to the measurable characteristics that are essential to meeting customer, user, or other validated stakeholder requirements. A CTQ gives an improvement team a precise definition of what acceptable performance looks like.
Customers rarely describe their needs in statistical or engineering language. A customer might say a product should be reliable, an order should arrive quickly, a website should be easy to use, or a medical appointment should start on time. These statements communicate what matters, but they are too broad to serve as process specifications by themselves.
The Six Sigma team translates that voice into measurable terms. “Fast delivery” might become an order-to-delivery time of no more than two business days for a defined service class. “Accurate invoice” might become a requirement that 99.5% or more of invoices contain no billing errors. The exact target must come from validated customer, business, technical, contractual, or regulatory requirements rather than an arbitrary number.
This translation is central to the Define phase of DMAIC and to Design for Six Sigma work. ASQ describes CTQ flowdown as a way to connect strategic focal points and project objectives to operational measurements. A CTQ tree performs a similar practical function by moving from a broad need through the drivers of that need to measurable performance requirements.
A well-defined CTQ normally answers several questions: What characteristic is being measured? How is it measured? What unit is used? What target or specification applies? What constitutes a defect or failure? Which customer or stakeholder requirement does it support?
CTQs are often treated as project Ys – the outputs a Six Sigma team wants to improve. The team then investigates the Xs, or process inputs, that drive those CTQ results. This creates a traceable chain from customer need to measurable output to the process factors that can be changed.
| Customer statement | Possible quality driver | Example CTQ |
| I need my order quickly | Delivery speed | Order-to-delivery lead time |
| The product must fit correctly | Dimensional conformity | Critical dimension within specification |
| Billing should be accurate | Invoice accuracy | Percentage of invoices with zero errors |
| The app should respond quickly | System responsiveness | Page response time under defined load |
| Appointments should start on time | Schedule reliability | Percentage starting within defined tolerance |
CTQ vs. Critical to Customer (CTC): Are They the Same?
CTQ and Critical to Customer (CTC) are closely related, but they are not always used as exact synonyms. Terminology varies across organizations and Six Sigma training programs, so teams should define the terms they use rather than assume every source follows the same convention.
A useful distinction is to treat a CTC as the customer-facing need, outcome, or measure that matters to the customer, and a CTQ as the measurable product, service, or internal performance characteristic required to deliver that outcome. Under this convention, CTC expresses what the customer values; CTQ translates that value into a specification the organization can manage.
For example, a hospital patient may value “not waiting too long.” That is a customer need and can be expressed as a CTC such as acceptable waiting experience or a customer-facing waiting-time requirement. The operational CTQs might include registration cycle time, time from check-in to triage, or the percentage of patients seen within a defined threshold.
Other organizations use CTQ broadly enough to include the customer-facing measure itself. That usage is also common. The practical issue is not the label; it is whether the project preserves traceability from Voice of the Customer to measurable requirements.
| Concept | Useful working definition | Example |
| Customer need / VOC | What the customer says or expects | “I want dependable delivery.” |
| CTC | Customer-facing outcome or requirement, when the organization uses this term separately | Orders arrive by the promised date |
| CTQ | Measurable characteristic/specification that must perform correctly to meet the requirement | On-time delivery rate ≥ validated target |
| Process X | Input or process factor that influences CTQ performance | Pick time, inventory availability, carrier cutoff |
This distinction prevents a common error: defining an internal metric as a CTQ simply because the organization already measures it. If customers care about delivery reliability, machine utilization is not automatically a CTQ. It may be an operational KPI or an X that affects delivery, but the team must demonstrate the connection to the customer requirement.
The same principle applies when requirements come from regulators, safety standards, contracts, or internal stakeholders rather than an external purchaser. A characteristic can be critical even when the end customer never articulates it directly. Teams should document the source of the requirement and why it is critical.
How to Identify CTQs – the CTQ Tree
A CTQ tree is a structured diagram that converts a broad customer need into increasingly specific, measurable performance requirements. The Minnesota Department of Health describes the tool as a way to translate broad customer needs and requirements into specific, measurable performance requirements. A common structure is Need → Quality Drivers → Measurable CTQs.
The tree is useful because it forces the team to separate what the customer wants from the factors that create that experience and from the actual metric used to judge performance.
Step 1: Identify the customer and capture the Voice of the Customer
Start by defining whose requirement is being translated. Customers may be external buyers, end users, patients, passengers, downstream departments, regulators, or other stakeholders. Gather evidence through interviews, complaints, surveys, observation, warranty data, support tickets, reviews, contract requirements, or other appropriate sources.
Record the need in customer language before converting it into technical terms. This reduces the risk that the organization substitutes its own assumptions for the customer’s priorities.
Step 2: Define the critical need
Summarize the underlying need at a useful level. “Good service” is usually too broad. “Resolve my issue without repeated contacts” is more actionable. The need should describe the outcome the customer values without prematurely prescribing a solution.
Step 3: Identify quality drivers
Drivers explain what must be true for the need to be satisfied. If the need is “dependable delivery,” drivers might include delivery speed, order accuracy, shipment completeness, and promise-date reliability. A driver is more specific than the need but may still require further translation before it can be measured consistently.
Step 4: Convert drivers into measurable CTQs
For each driver, define a characteristic that can be measured. A CTQ should have a clear operational definition, unit, measurement method, and performance requirement. If the driver is “quick response,” a CTQ might be median first-response time or the percentage of requests answered within a validated threshold.
Avoid inventing specifications simply to make the tree look complete. Targets and limits should come from customer research, engineering requirements, contracts, regulations, benchmark evidence, design needs, or another defensible source.
Step 5: Validate the CTQ
Ask whether meeting the CTQ would actually satisfy the original need. Also confirm that the metric can be measured reliably and that employees can influence the process that produces it. If a metric is easy to measure but weakly related to the need, return to the tree and refine it.
| CTQ tree level | Delivery example | Question to ask |
| Need | Dependable delivery | What outcome does the customer value? |
| Driver 1 | Speed | What aspect creates that outcome? |
| CTQ 1 | Order-to-delivery lead time | How will performance be measured? |
| Driver 2 | Reliability | What else shapes the need? |
| CTQ 2 | Percentage delivered by promised date | What measurable requirement represents success? |
| Driver 3 | Completeness | What else must be right? |
| CTQ 3 | Percentage of orders delivered complete | How will failure be defined? |
The finished CTQ tree should create traceability, not merely a list of metrics. A reviewer should be able to move backward from each CTQ and understand which quality driver and customer need justify measuring it.
CTQ Examples Across Industries
CTQs are not limited to manufacturing. Any product or service with measurable stakeholder requirements can use the concept. The examples below are illustrative; actual specifications should be validated for the organization, customer segment, product, and regulatory environment.
Manufacturing
A customer purchasing a precision shaft needs the component to fit and function reliably in an assembly. Possible CTQs include shaft diameter, roundness, surface finish, hardness, or runout. Each characteristic would have a drawing specification or other validated requirement. Defects occur when the applicable CTQ fails its requirement.
A second manufacturing CTQ might address delivery rather than physical quality. If customers require dependable supply, on-time delivery or order completeness can be just as critical as dimensional conformance.
Healthcare
A clinic may identify timely access as a critical patient need. CTQs could include appointment lead time, check-in-to-provider time, or the percentage of urgent requests handled within a defined clinical standard. Other CTQs might address medication accuracy, specimen labeling, or completeness of discharge instructions where those measures reflect validated safety and service requirements.
Banking and financial services
A customer applying for a loan may value speed, accuracy, and transparency. CTQs could include application decision time, percentage of error-free account documents, or the percentage of status updates delivered at required milestones. The team should distinguish customer-facing CTQs from internal productivity measures such as applications processed per employee.
Software and SaaS
For a software service, a customer need such as “the system must be available when I need it” can translate into availability, incident recovery time, transaction success rate, or response-time CTQs. Security requirements may also be critical, although the correct measures must come from the product’s risk and compliance framework rather than a generic CTQ template.
Logistics and e-commerce
Customers often care about receiving the correct order, in good condition, when promised. CTQs can include on-time delivery, perfect-order rate, picking accuracy, damage-free delivery, or order-to-delivery lead time. These outputs can then be linked to process Xs such as inventory accuracy, picking method, packing controls, carrier performance, and cutoff adherence.
Call centers and customer support
A support customer may need a problem resolved quickly and correctly. CTQs might include first-response time, first-contact resolution, repeat-contact rate, or customer-reported resolution quality. Average handle time should not automatically be labeled a CTQ: reducing it can harm the customer if agents rush calls without resolving issues.
| Industry | Customer need | Illustrative CTQ |
| Manufacturing | Part fits and performs | Critical dimension within engineering specification |
| Healthcare | Timely access | Appointment or waiting time against validated standard |
| Banking | Fast, accurate processing | Decision time and error-free documentation rate |
| Software | Reliable service | Availability or transaction success against service requirement |
| E-commerce | Correct order on time | Perfect-order or on-time-delivery performance |
| Customer support | Issue resolved effectively | First-contact resolution or repeat-contact rate |
Common Mistakes When Defining CTQs
A CTQ is useful only when it represents a genuinely important requirement and can be measured consistently. Poorly defined CTQs send DMAIC teams toward the wrong problem and can create impressive-looking dashboards that do not improve the customer experience.
Mistaking a vague need for a CTQ
“High quality,” “fast service,” and “easy to use” are needs, not finished CTQs. They need to be translated into observable characteristics and measurable requirements. If two analysts cannot determine the same result from the definition, the CTQ is not operationally clear enough.
Starting with internal metrics instead of the customer
Teams often select metrics that already exist because data are convenient. Utilization, labor efficiency, queue size, or number of transactions may matter operationally, but they are not automatically CTQs. Start with the need and work inward through the CTQ tree.
Using a target with no validated basis
A metric becomes more actionable when it has a target or specification, but an arbitrary threshold is not customer validation. Document where the requirement came from – customer research, engineering analysis, contract, regulation, service-level commitment, design specification, or another defensible source.
Confusing specification limits with control limits
Specification limits describe required performance or acceptance criteria. Control limits are statistically derived from process behavior and help determine whether a process is stable. A control limit should not be copied into a CTQ requirement simply because it appears on a control chart.
Defining too many CTQs
If everything is labeled critical, nothing is prioritized. A CTQ tree may identify several measures, but teams should focus on characteristics that materially determine whether the validated need is met. Supporting KPIs and process measures can remain important without being called CTQs.
Choosing a metric employees can game
A poorly selected CTQ can drive unintended behavior. For example, making short support-call duration the primary success metric may encourage agents to end calls quickly instead of solving problems. Use guardrail measures when optimizing one metric could damage another customer requirement.
Failing to define the measurement method
Terms such as “on time” or “error free” can hide ambiguity. Define start and stop points, inclusions and exclusions, units, data sources, sampling rules, and defect criteria. Measurement-system concerns apply to service data as well as physical measurements.
Failing to revisit CTQs
Customer expectations, products, regulations, technologies, and competitive conditions change. A CTQ that was critical three years ago may no longer differentiate performance, while a new requirement may have emerged. CTQs should be reviewed when Voice of the Customer evidence or operating conditions materially change.
Conclusion
CTQ is the bridge between what customers value and what a process can measure and improve. A strong CTQ begins with a validated need, identifies the drivers behind that need, and translates those drivers into clear performance requirements through a CTQ tree. The resulting measures give Six Sigma teams meaningful Ys for DMAIC rather than convenient internal metrics. By distinguishing CTQs from broader customer language, KPIs, process inputs, and statistical control limits, organizations can focus improvement work on characteristics that genuinely determine quality. The result is a clearer connection between customer expectations, process performance, and measurable improvement.
Frequently Asked Questions
What does OCAP stand for?
OCAP stands for Out of Control Action Plan — the pre-documented response operators follow when a control chart signals a special-cause variation. The plan tells them exactly what to check, what to adjust, and when to escalate.
When is an OCAP triggered?
An OCAP is triggered when a control chart shows a signal of special-cause variation — such as a point outside the control limits, an unusual run of points, or a trend pattern. The OCAP tells the operator exactly what to do next.
What does an OCAP document contain?
A good OCAP includes: the trigger condition (which control chart signal), the immediate check steps (what to inspect), the adjustment or corrective action, and the escalation path if the first-line action doesn’t resolve the issue.
Who writes the OCAP?
OCAPs are typically written by the process engineer or Six Sigma project team during the Control phase of DMAIC, with input from the operators who will use it. The best OCAPs are field-tested before being finalized.
