Voice of the customer (VOC) is the structured practice of collecting what customers need, want, and expect in their own words, then translating those statements into measurable, critical-to-quality requirements a process can be designed and controlled to meet. Raw VOC is a quote. A requirement is a number with a limit. The work of VOC is the bridge between the two.
Skip that bridge and every downstream decision floats. Teams optimize what is easy to measure instead of what the customer actually cares about, and a project can hit all its internal targets while the customer stays unhappy. This guide covers where VOC sits, how to gather it, and the step-by-step translation from a vague complaint into a spec you can chart on a control chart. It is the raw-VOC-to-CTQ bridge that anchors any Six Sigma project and grounds the customer column of a value stream map.
What is the voice of the customer?
The voice of the customer is the complete set of stated and implied customer needs, expressed in the customer's own language, captured before anyone inside the plant decides what to build or improve. It is distinct from the voice of the business (cost, margin, throughput) and the voice of the process (what the equipment can actually hold). All three matter, but VOC comes first because it defines what "good" means from the only perspective that pays the invoice.
VOC has two halves people routinely confuse. The first is reactive VOC: complaints, returns, warranty claims, and support tickets that arrive whether you ask or not. The second is proactive VOC: interviews, surveys, and observation you go out and gather on purpose. Plants that listen only to the reactive half improve only the things that already broke. The proactive half is where you catch the requirement nobody has complained about yet, because they simply left instead.
Why does raw VOC need translating?
Raw VOC needs translating because customer statements are almost never measurable as spoken. "The parts feel flimsy," "delivery is unreliable," and "the finish looks cheap" are real, useful signals, but no operator can inspect against "flimsy." The translation turns each statement into a critical-to-quality characteristic (CTQ): a specific, measurable feature with a target and a tolerance.
The chain has four links, and each link loses information if you skip it. A customer need ("I can trust the seal") becomes a driver (the seal does not leak), which becomes a CTQ (peel strength), which becomes a specification (peel strength 3.0-4.5 N/15mm, measured per the test method). Only the last link is chartable. Only the first link is what the customer actually said. VOC translation is the discipline of never losing the thread between them.
Where do you collect the voice of the customer?
You collect VOC from wherever customers already reveal what they value, plus a few channels you open on purpose. No single source is complete: complaints over-represent the angry, surveys over-represent the agreeable, and observation catches what people do rather than what they say. Triangulating across sources is how you avoid designing for a loud minority.
| Source | Type | Best for | Watch out for |
|---|---|---|---|
| Complaints, returns, warranty | Reactive | Known failure modes, urgent pain | Only captures problems that already happened |
| Customer interviews | Proactive | Depth, the "why" behind a need | Small sample; interviewer can lead the witness |
| Surveys (structured) | Proactive | Scale, ranking, quantified priorities | You only learn what you thought to ask |
| On-site observation / gemba | Proactive | Unspoken needs, real usage | Time-intensive; presence changes behavior |
| Sales and service notes | Reactive | Recurring themes across accounts | Filtered through the recorder's memory |
Whatever the channel, record VOC verbatim first and interpret second. The moment you paraphrase "it jams when I load it fast" into "improve feed reliability," you have thrown away the detail (loading speed) that would have pointed at the fix. Keep the original quote next to your interpretation so the translation stays auditable.
How do you turn a customer statement into a CTQ?
You turn a statement into a CTQ by walking it down a CTQ tree: from the broad need, to the drivers that satisfy it, to the specific measurable characteristics that prove each driver is met. The tree forces the vague top-level want to branch into things you can actually put a number on.
- Capture the statement verbatim. Write exactly what the customer said, in their words, with enough context to know who said it and when. This is the root of the tree and the anchor you will keep checking against.
- Name the underlying need. Ask what the customer is really trying to accomplish. "The box arrives crushed" is a statement; the need is "product arrives undamaged and looks new." Strip the proposed solution out of the need.
- Break the need into drivers. List the few things that would have to be true for the need to be satisfied. Undamaged arrival might depend on package strength, correct fill, and handling. Each driver becomes a branch.
- Define a CTQ for each driver. Pick a characteristic you can measure that indicates the driver. Package strength becomes edge-crush test value; correct fill becomes fill weight. If you cannot name a measurement, the driver is not yet specific enough.
- Set target and tolerance. Every CTQ needs a target and an allowable range, ideally sourced from what the customer will accept rather than what the process happens to do. This is the number the process will be held to.
- Confirm the measurement is trustworthy. Before locking the CTQ, check that two people measuring the same unit get the same result. A CTQ you cannot measure repeatably will lie to you on every chart afterward.
- Validate the CTQ back with the customer. Show the customer the target you derived and confirm it matches what they meant. This closes the loop and catches the translation errors that only surface when someone reads the number back.
How does the Kano model sort what customers ask for?
The Kano model sorts customer requirements by how satisfaction responds when you deliver them, splitting a flat wishlist into three very different categories. It stops teams from over-investing in features that never move the needle and under-investing in the ones that quietly lose accounts.
- Basic (must-be) needs. Expected and unspoken. Meeting them earns no credit; missing them causes anger. A sealed package that leaks fails a basic need. Customers rarely list these, which is exactly why observation matters.
- Performance needs. The more, the better, in a straight line. Faster delivery, tighter tolerance, longer shelf life. These are the needs customers can articulate and rank, so surveys catch them well.
- Delighter (attractive) needs. Unexpected features that spike satisfaction when present and cause no harm when absent. Today's delighter becomes tomorrow's basic expectation, so the category is a moving target.
The practical rule: nail every basic need before spending a dollar on delighters. A plant that ships an exciting new feature on a product that still arrives crushed has optimized the wrong end of the curve. Sort your CTQs into Kano categories before you prioritize the project scope.
By the numbers. The measurable end of the VOC chain is why Six Sigma exists: a process running at the six sigma level produces no more than 3.4 defects per million opportunities, roughly 99.99966% good, per the American Society for Quality (ASQ, What Is Six Sigma?). Quality Function Deployment, the formal method for carrying VOC through to engineering characteristics, was developed in Japan in the late 1960s and codified for Western industry through ASQ's body of knowledge (ASQ, Quality Function Deployment). Both frameworks share one premise: an unmeasured customer need is an unmanaged one.
Where does VOC fit in a Six Sigma project?
VOC lives in the Define phase of DMAIC and it is the input that makes everything after it honest. The problem statement, the project scope, the metric you will improve, and the goal you will declare victory against all descend from VOC. Get it wrong and a technically flawless project solves a problem nobody had. The CTQs you derive here become the Y in the measure phase, the characteristics you baseline, chart, and prove capable.
For a fuller treatment of how CTQs become measurable outputs, see critical-to-quality and, for prioritizing which CTQs matter most, the Kano model and quality function deployment guides. VOC also feeds lean work directly: the customer column of a value stream map is VOC in map form, and the definition of value that drives every lean improvement is VOC by another name.
The hard part on a real floor is not gathering VOC once; it is keeping the trace from a customer quote to a live control chart intact as people and shifts change. When customer requirements, CTQs, and the checks that verify them live in scattered spreadsheets, the thread breaks and the plant drifts back to inspecting what is easy. Harmony keeps that chain connected by digitizing station-level quality capture so the CTQ a customer cares about is the one the operator is actually checking, timestamped and searchable. See how one plant tied floor checks to customer requirements in our CLS case study. No rip-and-replace; the voice of the customer just stops getting lost in translation.