From a Vague Complaint to Measurable Quality: A CTQ Tree in Action

A regional service centre opened a project with a familiar goal: 'Make the intake process better for the public.' Better how? The improvement team had survey comments, anecdotes, and a sponsor who was sure something needed fixing — but nothing they could measure or target. This is exactly the gap a Critical-to-Quality (CTQ) tree is built to close. The names below are anonymized, but the method is standard Lean Six Sigma.

What a CTQ tree does

A CTQ tree translates a broad, fuzzy customer need into the specific, measurable characteristics your process must deliver. It works in three layers, left to right. You start from the Voice of the Customer — what people actually say. You move to the customer's underlying need — the driver behind the comment. Then you break that need into CTQs: measurable requirements with a target and a tolerance. The discipline is forcing yourself not to stop until you reach something you can put a number on.

Here is how the service centre's team worked one branch:

1. Voice of the Customer. 'I waited forever and nobody told me what was happening.' Raw, emotional, not yet measurable.

2. Need. Two distinct needs hide in that one sentence: timely service, and clear communication about status. Splitting them matters — they have different measures.

3. CTQ for timeliness. Initial response within 10 minutes of arrival; total handling time under 30 minutes for a standard request.

4. CTQ for communication. Every waiting person receives a status update at least every 15 minutes; expected wait time is posted on arrival.

Why the splitting matters

The team's first instinct had been to treat the whole thing as a speed problem and throw staff at the queue. The CTQ tree revealed that half the frustration was about silence, not slowness — a communication CTQ, far cheaper to fix than adding headcount. Without decomposing the need, they would have spent the budget on the wrong CTQ. A good tree often reveals that one complaint contains several requirements that compete for different solutions.

Practical rules for building one

• Start from real Voice-of-the-Customer data, not your own assumptions about what people want.

• Keep asking 'what would have to be true for the customer to feel this need is met?' until the answer is measurable.

• Every leaf CTQ needs a metric, a target, and a tolerance — 'fast' and 'friendly' are not CTQs until they carry numbers.

• Split a need into separate branches when it hides more than one requirement, as timeliness and communication did here.

• Validate the tree with a few real customers before you build improvements on top of it.

Built early, a CTQ tree anchors the rest of a DMAIC project: the CTQs become what you measure in the Measure phase and what you prove improved in Control. In a period when service expectations shifted fast and many teams were under strain, a tree is a cheap way to make sure you are improving what customers actually care about rather than what is easiest to count.

If you have strong signals that something needs to improve but no clear, measurable target, XNM's strategic advisory can help you turn customer needs into requirements you can act on.