Six Sigma Foundations — Part 3 of 5
Here’s a scenario that will be familiar to most support leaders: your weekly CSAT report comes in and this week’s score is 82%, down from 86% the week before. Your VP asks what happened. Your team scrambles for an explanation. You point to the three escalations that went badly. You commit to a coaching session. Next week the score is 85% and everyone moves on.
But what if nothing happened? What if 82% and 86% are both completely normal for your operation — within the natural variation of the process — and the explanation you gave was a story you told about noise?
This is the central problem that statistical process control (SPC) and control charts are designed to solve. They give you a principled way to distinguish between variation that’s telling you something and variation that isn’t. And once you can make that distinction, it changes how you manage.
I’ve written about measuring performance and choosing what to measure before — but those posts answer the question of what to track. Control charts answer the harder question of what your data is actually telling you. This is Part 3 of my Six Sigma series. If you’re just joining, start with Part 1: What Six Sigma Is and Why It Matters for Support Leaders and Part 2: DMAIC — The Framework Behind Every Process Improvement I’ve Made.
Two Types of Variation
Before we look at control charts, you need to understand the most important distinction in all of statistical process control: common cause variation vs. special cause variation.
Walter Shewhart, who developed SPC at Bell Labs in the 1920s, defined it this way:
Common cause variation (also called “noise”) is the natural, inherent variation in a stable process. It’s the fluctuation you’d expect to see even when nothing has changed and everything is working as designed. Your CSAT score varying between 82% and 87% from week to week might simply be common cause variation — the normal statistical behaviour of a process operating consistently.
Special cause variation (also called “signal”) is variation caused by a specific, identifiable factor outside the normal process. A sudden drop to 71% CSAT during a week where your platform had a major outage — that’s a signal. Something specific happened, and it’s worth investigating.
The critical mistake most leaders make — reacting to common cause variation as if it were a signal — is called tampering, and it actually makes processes worse. Every time you intervene in a stable process because of a data point that’s within normal variation, you introduce additional variation. You’re adding noise.
Control charts make this distinction visible.
What Is a Control Chart?
A control chart is a time-series graph of a process metric with three horizontal reference lines:
- The center line (CL): The average (mean) of your data over a defined period
- The upper control limit (UCL): The average plus three standard deviations
- The lower control limit (LCL): The average minus three standard deviations
Any data point that falls between the UCL and LCL, with no non-random patterns, is common cause variation — the process is in statistical control (stable and predictable). Any data point outside those limits is a signal — something unusual happened and it’s worth investigating.
The three-sigma limits aren’t arbitrary. Statistically, if a process is in control, roughly 99.73% of all data points should fall within three standard deviations of the mean. A point outside those limits is a rare event — rare enough that it’s unlikely to have happened by chance, which means something caused it.
Types of Control Charts and Which to Use in Support Operations
There are several types of control charts, and choosing the right one depends on what you’re measuring. Here are the most relevant for support and CX environments:
P-Chart (Proportion Chart) Used for tracking the proportion of defective outcomes in a sample. This is my most frequently used chart in support operations. Applications include: FCR rate (proportion of tickets resolved on first contact), SLA compliance rate, escalation rate, and CSAT score (if you’re scoring binary: satisfied vs. not satisfied).
Example: Plotting weekly SLA compliance rate (what % of tickets were resolved within SLA) over 26 weeks. Your P-chart will show you whether compliance is stable and what your natural variation range is, so you can tell the difference between a bad week and a genuine performance shift.
C-Chart (Count Chart) Used for counting the number of defects (not the proportion) when the sample size is constant. Useful for: number of escalations per week, number of SLA breaches per day, number of quality audit failures per 100 tickets reviewed.
U-Chart (Count Per Unit Chart) Like the C-Chart but for when sample sizes vary. Use this for: defects per ticket (when ticket volume varies), complaints per 1,000 interactions.
X-bar and R Chart (Average and Range Chart) Used for continuous data measured on a scale. In support: average handle time, average first response time, average resolution time. The X-bar chart plots the average of each subgroup; the R chart plots the range within each subgroup. Together they tell you about both the central tendency and the spread of your performance.
I-MR Chart (Individuals and Moving Range Chart) The simplest chart — used when you have individual measurements rather than subgroups. Useful for daily ticket volume, daily CSAT score, weekly NPS.
If you’re not sure where to start, the P-chart and I-MR chart cover the majority of support operations use cases and are the most accessible to build and interpret.
How to Build a Basic Control Chart (Without Dedicated Software)
You don’t need Minitab or specialized SPC software to start using control charts — though they’re worth the investment once you’re using them regularly. You can build a functional control chart in Excel in under an hour.
Here’s the basic process:
- Collect at least 20–25 data points from a stable period (before any major changes). Less than 20 and your control limits won’t be reliable.
- Calculate the mean of your data series.
- Calculate the standard deviation using the appropriate formula for your chart type (Excel’s STDEV function works for I-MR charts).
- Set UCL = Mean + (3 × Std Dev) and LCL = Mean – (3 × Std Dev).
- Plot the time series with center line, UCL, and LCL as horizontal reference lines.
- Apply the detection rules (see below).
For P-charts, the standard deviation calculation is slightly different: σ = √(p̄(1−p̄)/n), where p̄ is the average proportion and n is the sample size. This accounts for the binomial nature of proportion data.
If you’re already building operational dashboards — the kind covered in the customer journey dashboard case study on datadrivenops.co — adding control chart logic to your existing reporting layer is a natural extension. You already have the data; it’s a matter of adding the statistical reference lines.
The Four Main Signal Rules
A process is considered out of statistical control — a signal worth investigating — when any of the following occur:
- Any single point falls outside the UCL or LCL. The most obvious signal.
- Eight or more consecutive points on the same side of the center line. This indicates the process has shifted — even if every point is within the control limits individually.
- Six consecutive points trending steadily up or down. The process is drifting in a direction.
- Two out of three consecutive points fall in the outer third of the control limits (between 2σ and 3σ). A warning sign of instability.
These rules — sometimes called the Nelson rules or Western Electric rules — give you a structured, consistent way to identify signals without relying on judgment calls.
What I’ve Learned From Control Charts in Practice
The most transformative thing about adopting control charts wasn’t the charts themselves — it was the shift in how I ran performance conversations.
Before control charts, a weekly metrics review was often a search for explanations. Why was CSAT lower this week? Why did handle time spike on Wednesday? The team would generate narratives — some legitimate, some retrofitted to fit the data point — and commitments would be made to address things that were often just noise.
After adopting control charts, the question became: is this a signal or is it common cause variation? If a data point is within our control limits and there’s no non-random pattern, we don’t chase it. We acknowledge it, note it, and move on. If something is genuinely outside the control limits, we investigate with purpose — and we document what we find.
This reduced the amount of reactive churn in my teams significantly. It also made performance discussions more honest, because we stopped pretending we could explain every fluctuation in every metric.
There’s one other thing control charts showed me that I didn’t expect: they revealed how wide our natural variation actually was. Before building a proper control chart for our average handle time, I thought our performance was reasonably consistent. The chart showed control limits nearly 4 minutes apart. We weren’t nearly as stable as we thought. That insight launched a process improvement project that tightened the variation significantly — and that’s exactly what control charts are supposed to do.
Building and maintaining dashboards like this is also directly relevant to what I cover on the BI & Dashboards pillar at datadrivenops.co — the discipline of building reports that drive decisions, not just reports that get filed.
Control Charts and the DMAIC Connection
Control charts appear in two phases of DMAIC (covered in Part 2 of this series):
- Measure phase: Building baseline control charts to understand current process stability before attempting improvement.
- Control phase: Implementing ongoing control charts to monitor the improved process and detect if it regresses.
A control chart built on pre-improvement data gives you a baseline. After you implement changes, you recalculate the control limits based on the new data. If the new center line is better and the variation is tighter, you have statistical evidence that your improvement worked — not just a gut feeling.
We’ll come back to the Control phase in depth in Part 5 of this series. Next, we’re going to look at the diagnostic toolkit: how to find the root cause of a problem before you try to solve it. Part 4: 5 Whys, Fishbone Diagrams, and the 7 Quality Tools →
Hutch Morzaria is a Director-level CX and Support Leadership professional with 19 years of experience building global support organizations across SaaS, Fintech, and enterprise technology. He has hired dozens of support and CX leaders across his career and holds ITIL Expert certification across V3 and V4.