Voice of the Process: Why Your Data Is Already Telling You the Answer (and You’re Not Listening)

In the realm of Lean Six Sigma, improvement decisions should not be driven by the loudest opinion in the room. They should be guided by evidence.

That evidence is the Voice of the Process (VOP): the story told by cycle times, defect rates, control charts, rework levels, customer outcomes, and process variation. While teams often collect customer feedback carefully, they may overlook what their own process data is revealing every day.

The fundamental purpose of Voice of the Process analysis is to answer a practical question:

Can our current process consistently deliver what customers require?

To fully appreciate the answer, you must compare the Voice of the Customer (VOC) with the Voice of the Process. VOC defines the desired performance. VOP reveals actual performance. Process capability measures such as Cp and Cpk show whether the process can reliably bridge the gap.

Voice of the Customer vs. Voice of the Process

Voice of the Customer represents customer needs, expectations, preferences, and limits. It may be captured through:

  • Surveys and interviews
  • Complaints and support tickets
  • Service-level agreements
  • Customer journey research
  • Returns, claims, and warranty records
  • Customer satisfaction and loyalty data

VOC often begins with an expression such as:

  • “I need my claim resolved quickly.”
  • “I want the payment to be accurate the first time.”
  • “I need a response within one business day.”

These statements are valuable, but they are not yet measurable requirements. Lean Six Sigma teams translate them into Critical to Quality (CTQ) characteristics.

For example:

Customer statement CTQ Measurable requirement
“Resolve my claim quickly.” Claim cycle time No more than 5 business days
“Pay me accurately.” First-pass payment accuracy At least 99% correct
“Keep me informed.” Update compliance 95% of customers receive updates within 48 hours

The Voice of the Process shows whether the process is meeting these requirements. It is based on actual operational data, such as:

  • Average and median cycle time
  • Standard deviation
  • Defect and error rates
  • First Pass Yield
  • Rework frequency
  • Process capability
  • Control chart signals
  • Performance by team, location, product, or shift

VOC tells you what the process should deliver. VOP tells you what the process is delivering.

Infographic comparing Voice of the Customer requirements with Voice of the Process data

Specification Limits and Control Limits Are Not the Same

A common mistake is to treat customer specifications and process control limits as interchangeable. They answer different questions.

Specification limits come from the customer, regulator, contract, or business requirement. These are usually expressed as:

  • USL: Upper Specification Limit
  • LSL: Lower Specification Limit

For a claims process, the customer requirement might be a maximum cycle time of five business days. In that case, five days is the USL.

Control limits are calculated from process data. They represent the expected natural range of a stable process, commonly based on the process mean and approximately three standard deviations above and below it.

Control limits answer:

Is the process stable and predictable?

Specification limits answer:

Does the process meet customer requirements?

A process can be stable but incapable. For example, a claims process might consistently take between six and eight days. Its performance may be predictable, but it still fails the customer requirement of five days.

This distinction is essential. Before calculating capability, confirm that the process is reasonably stable using an appropriate control chart. If special causes are present, calculate capability only after investigating them or clearly separating the analysis into relevant conditions.

How Cp and Cpk Let You Hear the Process Clearly

Process capability indices compare the natural spread of a process with the customer specification window.

Cp: Potential Capability

The formula for Cp is:

[
Cp = \frac{USL – LSL}{6\sigma}
]

Cp evaluates whether the process variation is narrow enough to fit within the specification limits. It does not account for whether the process is centred.

  • Cp below 1.00: The process spread is wider than the specification window.
  • Cp around 1.00: The process is only marginally capable if perfectly centred.
  • Cp of 1.33 or higher: A commonly used performance benchmark.
  • Higher Cp: Greater potential capability, assuming the process is centred and stable.

Cpk: Capability Including Centreing

The formula for Cpk is:

[
Cpk = \min\left(\frac{USL-\mu}{3\sigma},\frac{\mu-LSL}{3\sigma}\right)
]

Cpk considers both process variation and the location of the process mean.

A process may have a strong Cp but a weaker Cpk if its average performance is shifted toward one specification limit. This is why:

Cp shows potential. Cpk shows practical capability.

For a one-sided requirement, such as “complete the claim within five days,” teams may use a one-sided capability calculation. If a lower boundary is included for mathematical illustration, it should be clearly identified as an operational assumption rather than a customer requirement.

Finance Claims Example: When VOP Exposes the Capability Gap

Consider a hypothetical insurance claims process handling 4,000 claims per month.

Step 1: Translate VOC into CTQs

Customer research reveals two consistent expectations:

  1. Claims should be settled within 5 business days.
  2. Payments should be correct the first time.

The project team defines:

  • CTQ 1: Claim cycle time, with USL = 5 business days
  • CTQ 2: First-pass payment accuracy, with LSL = 99%

Step 2: Measure the Voice of the Process

The team reviews three months of data and finds:

  • Average claim cycle time: 7.0 business days
  • Standard deviation: 1.5 business days
  • First-pass payment accuracy: 97.0%
  • Monthly rework volume: 320 claims
  • Average cost of reworking one claim: $42

The process is stable on its control chart, but the mean cycle time is consistently above the customer limit.

Step 3: Calculate Capability

For an illustrative two-sided cycle-time model, assume:

  • LSL = 0 business days
  • USL = 5 business days
  • Mean, μ = 7.0 days
  • Standard deviation, σ = 1.5 days

Potential capability:

[
Cp = \frac{5-0}{6(1.5)}=\frac{5}{9}=0.56
]

This Cp of 0.56 indicates that the natural process spread is too wide for the specification window.

Now calculate Cpk:

[
Cpk = \min\left(\frac{5-7}{3(1.5)}, \frac{7-0}{3(1.5)}\right)
]

[
Cpk = \min(-0.44, 1.56) = -0.44
]

The negative Cpk is a clear signal: the process mean is already beyond the customer’s maximum acceptable cycle time.

Accuracy tells a similar story. With an average of 97% against a minimum requirement of 99%, the process is systematically below the CTQ. The data is not merely showing occasional variation. It is showing a process that requires improvement in both speed and accuracy.

The financial effect is also material:

[
320 \text{ reworked claims} \times $42 = $13,440 \text{ per month}
]

That represents $161,280 in annualised rework cost, before considering customer dissatisfaction, additional handling time, and delayed cash flow.

Step 4: Improve and Recalculate

The team enters the Analyse and Improve phases of DMAIC. Root-cause analysis identifies:

  • Manual document verification
  • Inconsistent claim-routing rules
  • Duplicate data entry
  • Uneven workload allocation
  • Unclear payment validation criteria

The team implements standard work, automated validation checks, clearer routing rules, and workload balancing. The new results are:

  • Average cycle time: 3.5 business days
  • Standard deviation: 0.5 business days
  • First-pass accuracy: 99.3%

Recalculating cycle-time capability:

[
Cp = \frac{5-0}{6(0.5)}=\frac{5}{3}=1.67
]

[
Cpk = \min\left(\frac{5-3.5}{3(0.5)}, \frac{3.5-0}{3(0.5)}\right)
]

[
Cpk = \min(1.00, 2.33)=1.00
]

The process is now substantially better aligned with VOC. However, Cpk of 1.00 suggests that further centreing and variation reduction may still be appropriate if the organisation’s target is 1.33 or higher.

Before-and-after process capability comparison for a hypothetical insurance claims process

Good Problem Statement Examples for VOP Analysis

A strong problem statement describes the gap without prematurely assigning a cause or solution. It should include the process, measurable performance, timeframe, and impact.

Weak example

The claims team needs better training.

This assumes the cause before analysis.

Good problem statement example 1

Between January and March, the insurance claims process averaged 7.0 business days against a customer requirement of no more than 5 business days, with a standard deviation of 1.5 days. The gap affects approximately 4,000 monthly claims and contributes to avoidable rework and delayed customer payment.

Good problem statement example 2

First-pass payment accuracy was 97.0% from January to March, below the CTQ requirement of 99%. Approximately 320 claims per month required rework, creating an estimated monthly rework cost of $13,440.

Good problem statement example 3

Although the claims process is statistically stable, its average cycle time remains above the customer specification, indicating a capability gap rather than an isolated performance event.

These examples are specific, measurable, and neutral. They create a strong foundation for the Define phase without directing the team toward an unverified solution.

Where VOP Fits Within DMAIC

Voice of the Process strengthens every phase of the DMAIC framework:

  1. Define: Capture VOC and translate customer needs into CTQs and project requirements.
  2. Measure: Establish a reliable baseline using operational data and confirm the measurement system.
  3. Analyse: Use control charts, Pareto analysis, process maps, hypothesis tests, and Cp/Cpk to identify the nature of the gap.
  4. Improve: Reduce variation, centre the process, remove waste, and test solutions against CTQ performance.
  5. Control: Maintain alignment using control plans, standard work, dashboards, audits, and ongoing capability monitoring.

The most effective projects do not choose between VOC and VOP. They connect them. Customer feedback defines value, while process data shows whether the organisation can deliver that value consistently.

Improvement team translating customer needs into CTQs through the DMAIC framework

Start Listening to the Data

Your process is already communicating. The question is whether your team has defined the right CTQs, collected dependable data, and compared actual performance with customer expectations.

When VOP is separated from VOC, teams may optimise internal metrics that customers do not value. When the two voices are connected through DMAIC and capability analysis, improvement becomes more precise. You can see whether the primary issue is excessive variation, poor centreing, unstable performance, or an unclear specification.

Build the skills to interpret process data, translate VOC into CTQs, and lead measurable improvement projects by pursuing Lean Six Sigma training and professional certification with Lean 6 Sigma Hub. Explore the CSSC-accredited Green Belt training or review the full range of self-paced Lean Six Sigma courses.

Kaizen. Kai-Care. Kai-Done. ( Lean Six Sigma)

Related Posts