Critical to Quality

Critical to quality is a measurable requirement that translates what a customer actually cares about into a specification a process can be held to. It is the bridge between a customer’s words and an operational target, and it is always expressed numerically.

Customers rarely speak in specifications. They say they want a fast answer, and the job is to turn that into a number with a limit, a unit, and a way to measure it.

Without that translation, improvement work has nothing to aim at. Teams end up optimising whatever is easiest to count instead of whatever the customer noticed.

Key takeaways

• Critical to quality requirements convert customer needs into numeric, measurable specifications.
• Each one needs a metric, a target, and an acceptable tolerance range.
• They are derived from customer evidence, not from internal assumption.
• A good requirement is one the customer would recognise as their own concern.

How it works

Critical to quality requirements are derived by collecting customer needs, grouping them into drivers, then attaching a measurable specification to each driver. The chain runs from a vague statement to a number a process owner can be held to.

The derivation has three steps: need, driver, then measurable requirement.

Take a customer who says “I don’t want to be kept waiting”. The driver is responsiveness, and the requirement becomes answering 80% of contacts inside 20 seconds.

Each row is testable — which is the whole point. A requirement nobody can measure is an aspiration wearing a specification’s clothes.

The raw material comes from customer evidence.

The American Society for Quality describes the voice of the customer as engagement with customers and stakeholders to understand their needs, which should sit central to strategy and key performance indicators — see ASQ’s voice of the customer resource.

Those requirements then drive improvement work. In Six Sigma, they define what “defect” means, and everything downstream depends on getting them right.

Tolerance matters as much as target. A requirement with no acceptable range produces either constant failure reports or meaningless pass rates.

Requirements should be few. Four to six per service line is workable — while twenty becomes a scorecard nobody reads and nobody manages against.

Reviewing them belongs to quality assurance, because the scorecards used to judge individual work should trace back to the same requirements.

Federal service standards follow the same logic from the customer side. The U.S. federal customer experience program collects and publishes service-provider feedback so agencies are accountable for what customers actually experience.

Requirements decay. Products change, channels change, and a requirement written three years ago may now measure something customers stopped caring about.

Conflicts must be resolved deliberately. Speed and accuracy pull against each other, so someone has to state which one wins when both cannot be met.

Examples

Critical to quality requirements look different by industry, but the derivation is always the same: customer statement, then driver, then number. Five cases show the range.

Contact centres translate impatience into answer-speed targets. “Nobody picks up” becomes a service-level requirement with a stated percentage and a stated number of seconds.

Manufacturers translate fit complaints into tolerances. “It rattles” becomes a dimensional specification with an upper and lower limit that inspection can verify.

Healthcare providers translate anxiety into turnaround times. “I waited days for my result” becomes a reporting requirement measured in hours from sample receipt.

Financial services translate distrust into accuracy limits. “My statement was wrong” becomes an error-rate ceiling that audit samples test monthly.

Outsourced delivery teams translate client language into contract terms. Requirements written this way end up in the service agreement directly — which is why sloppy derivation creates years of argument.

Related terms

Critical to quality requirements sit at the front of every improvement method and behind most service agreements. The terms below cover the methodology, the customer evidence, and the reporting they feed.

• Six Sigma: the improvement methodology that uses these requirements to define defects.
• Quality Assurance: the review function whose scorecards should trace back to them.
• Customer Effort Score: a customer-side measure often used to test whether requirements were set correctly.
• Service Level Agreement (SLA): the contract where these requirements usually end up.
• Business Process Improvement: the discipline that redesigns processes to meet them.
• Key Performance Indicator (KPI): the reported measure a requirement becomes once live.
• Balanced Scorecard: the framework that keeps quality requirements beside financial ones.

FAQ

What does critical to quality actually mean?

It means a customer requirement expressed as a number a process can be measured against, with a target and a tolerance.

How is it different from a key performance indicator?

A critical to quality requirement is the customer-derived specification, while a key performance indicator is the measure reported against it internally.

Where do the requirements come from?

From customer evidence such as surveys, complaints, interviews, and contact reasons, grouped into drivers before being made numeric.

How many should a service have?

Four to six per service line is manageable; beyond that, nobody can prioritise between them.

What makes a bad requirement?

Anything unmeasurable, anything the customer would not recognise, and anything without a stated tolerance.

How often should they be reviewed?

Annually, or whenever the product, channel mix, or customer base changes materially.

Source partners designing measurable service commitments can compare delivery models across Outsource Accelerator hubs.