Voice of the Process

Voice of the process is the signal a process gives through its actual performance data, variation, and outcomes. It tells a team what the process can deliver today, not what customers want, leaders hope for, or documentation says should happen.

The phrase is common in Six Sigma, quality management, and process improvement. A team listens to the voice of the process by measuring work over time: cycle time, error rate, throughput, wait time, rework, defects, service levels, or other indicators that show how the process behaves in practice.¹

Most teams have three different stories about a process:

• What customers or downstream teams need.
• What the business wants.
• What the process can actually deliver today.

Voice of the process focuses on the third story. That is where improvement work gets honest. A manager may want same-day approvals, and customers may expect faster onboarding. But if the current process has a five-day backlog, unclear ownership, and frequent rework, the process is saying something else.

Listening to the voice of the process keeps improvement conversations grounded in evidence instead of the loudest complaint, the most recent incident, or the tidy version of the process shown in a diagram.

Voice of the customer and voice of the process need each other, but they answer different questions.²

The voice of the customer may say, "Customers need onboarding completed within two business days." The voice of the process may say, "We only hit two days when one experienced coordinator is available and no access issues occur." Both voices are useful. Ignoring either one creates bad decisions.

A process does not speak in opinions. It speaks through signals such as:

• Average cycle time and the range around it.
• Defect or error rates.
• Queue size and waiting time.
• First-pass yield or rework frequency.
• Missed deadlines or service-level failures.
• Variation by team, location, system, product, or request type.
• Patterns over time, such as spikes, drift, or recurring bottlenecks.

Variation is often the most useful signal. A process that averages two days but sometimes takes ten days is not as reliable as a process that usually takes three days. Averages can hide the experience people actually have.

That is why voice of the process is often connected to charts and time-ordered performance data. A time-ordered view can help teams see whether performance is stable, drifting, or being disrupted by unusual causes that deserve investigation.³

Start with one process and one outcome that matters. For example: "How long does it take to approve a new customer account?" or "How often does a support ticket need rework after the first response?"

Then keep the measurement path narrow:

• Define the process boundary: trigger, start point, end point, and owner.
• Choose one or two meaningful measures.
• Collect data from real work over time, not just one snapshot.
• Look for patterns, variation, delays, and outliers.
• Compare process performance with customer or business requirements.
• Improve the process, then keep measuring to see whether behavior changed.

The trap is measuring whatever is easiest because it is already in a dashboard. Activity counts may say very little about whether the process is healthy.

The first mistake is treating the documented process as the real process. A workflow diagram may show what should happen. Voice of the process shows what is happening.

The second is reacting to every outlier as if the whole process is broken. Some variation is normal. The improvement question is whether the process is stable, capable, and aligned with customer needs.

The third is using customer complaints as the only signal. Complaints matter, but they are incomplete. Some process failures never become complaints because customers give up, employees compensate manually, or the issue stays hidden downstream.

The fourth is changing the process before understanding the baseline. Without a baseline, teams may not know whether the change helped, harmed, or simply moved the problem somewhere else.

Use this checklist before acting on process data:

Voice of the Process Checklistmarkdown

Copy to AI

ChatGPTClaudeGeminiPerplexity

Paste into ChatGPT, Claude, Gemini, or Perplexity and personalize for your use case

## Voice of the Process Checklist

**Glossary term:** Voice of the Process
**Source:** Trails Glossary — trails.so/glossary/voice-of-the-process

---

### 01. Review process data before acting

"Process: [name]
Boundary: Starts when [trigger] and ends when [definition of done]
Primary measure: [cycle time, error rate, backlog, first-pass yield, etc.]
Data period: [date range]
Data source: [system, report, observation, sample]
Customer or business requirement: [target or expectation]
Observed performance: [what the process is actually doing]
Variation pattern: [stable, drifting, spiking, inconsistent by team/tool/type]
Likely causes to investigate: [handoff, unclear rule, queue, defect, missing input]
Documentation gap: [missing SOP, unclear step, undocumented exception, stale guide]
Next test: [small process change to try]"

This keeps the discussion tied to a real process, real data, and a specific improvement action.

Voice of the process and documentation work best together. Documentation explains the intended method: who does what, in what order, with which standards and exceptions. Process data shows whether that method is producing the expected result.

If the data shows high variation, documentation may be part of the diagnosis. Maybe the steps are unclear. Maybe different teams interpret the same policy differently. Maybe the exception path lives in one person's memory instead of the shared guide.

But documentation is not a substitute for measurement. A polished SOP cannot prove that a process is stable or capable. It can only make the work easier to perform consistently, which gives the team a better foundation for measurement.

Trails helps teams capture the actual workflow people follow and turn it into a clear step-by-step guide. That is useful when the voice of the process suggests inconsistency, rework, or unclear handoffs.

Trails does not replace process measurement, but it can help teams standardize the method they are measuring so improvement work has a firmer base.

Is voice of the process the same as process metrics?

Not exactly. Process metrics are the measurements. Voice of the process is the interpretation of what those measurements reveal about the process's current behavior and capability.

Can voice of the process be used outside manufacturing?

Yes. Any repeatable process can have a voice: customer onboarding, support triage, claims review, invoice approval, hiring, fulfillment, IT access requests, or internal reporting.

What is the difference between voice of the process and voice of the customer?

Voice of the customer describes what customers or downstream users need. Voice of the process describes what the process can actually deliver today. Improvement work often happens in the gap between the two.