Why Average Process Times Hide Operational Problems

A three-day average cycle time sounds fine. It sounds fine right up until a customer calls asking why their claim, submitted eleven days ago, still has not been resolved. Both statements can be true at once: the average across all claims really is three days, and a specific claim really has taken eleven. An average is a single number standing in for an entire spread of outcomes, and by design it discards the shape of that spread, including the part of it that is causing the most damage.

How an average can quietly mislead a whole team

An average is calculated by adding up every value and dividing by the count, which means a small number of very fast cases can offset a small number of very slow ones and produce a middle-of-the-road figure that describes neither group accurately. Picture a process where seventy cases complete in one day, twenty take three days, and ten take fifteen days because they hit an exception or a rework loop. The average across all one hundred cases comes out close to two and a half days, a number that does not describe the seventy fast cases, does not describe the twenty typical ones, and badly understates what is happening to the ten slow ones. Anyone reporting only the average has, in effect, made the slowest and most troublesome cases invisible in the very number meant to summarize performance.

This is not a hypothetical distortion. It is the normal shape of most business processes, because most processes have a core of straightforward cases that move quickly and a smaller tail of cases that hit an exception, need an escalation, or get stuck behind a queue. The average sits somewhere in the middle of that shape and describes almost none of it precisely.

Why the slow tail is usually where the real damage happens

The cases that take far longer than typical are usually the ones doing the most reputational and operational harm, even though they represent a minority of total volume. A customer who waited three days for a routine request rarely complains. A customer who waited three weeks usually does, and that complaint often lands on a manager's desk regardless of how good the average performance was that month. The slow tail also tends to correlate with the cases that carry the most complexity or the highest value, which means the cases an organization can least afford to mishandle are exactly the ones an average is most likely to obscure.

Ignoring the tail also removes an early warning signal. A growing tail, even while the average stays flat, is often the first visible sign that a process is losing capacity somewhere, whether that is a resource going on leave, a policy change adding friction to certain cases, or a supplier starting to respond more slowly. A team watching only the average would not notice any of this until it had grown large enough to drag the average itself upward, by which point the underlying problem has usually been building for some time.

What to look at instead of a single average

The more useful approach is to look at the distribution of cycle times directly, and to describe performance using a small number of reference points drawn from that distribution rather than a single blended figure. The median describes the typical case, unaffected by a handful of extreme outliers in either direction. A tail measure, such as the cycle time that only a small proportion of cases exceed, describes how bad the worst realistic cases get. Looking at both together, rather than a single average sitting between them, gives a far more honest and more actionable picture of how the process is actually performing.

Why simulation is what makes this visible

The reason distribution-based measures are rarely used in everyday reporting is not that they are complicated, it is that most process reporting only has access to a handful of historical figures and defaults to summarizing them the simplest way possible, which is an average. A discrete-event simulation run across hundreds of cases produces the full distribution directly, because it is generating the individual case outcomes rather than summarizing a small batch of historical ones. That makes it straightforward to look past the average and see the median, the tail, and everything in between, including how those figures shift when a specific step or resource changes.

How Processfix reports this

Processfix does not summarize simulation results down to a single average. It reports P50, P90, and P95 cycle time for the baseline and for every Improve or Add AI scenario built on top of it, so a team can see the typical case and the slower tail side by side, and can judge whether a proposed change genuinely reduces risk for the cases that matter most, rather than just producing a better-looking headline figure. That comparison, alongside throughput, utilization, and bottleneck location, is what sits behind the objective-led recommendations a team reviews before approving or rejecting a change.