Waiting Time vs Service Time in a Business Process

Ask someone how long it takes to process a mortgage application, approve an expense claim, or resolve a customer complaint, and they will usually describe the work itself: how long it takes to review the documents, how long it takes to key in the numbers, how long it takes to write the response. That is service time, the time a case is actually being touched by a person or a system. It is rarely the whole story, and in most processes it is not even the majority of the story.

The other component is waiting time: the time a case sits in a queue, an inbox, or a shared folder before anyone starts working on it. A claim that takes twenty minutes to actually assess might sit untouched for three days before an assessor picks it up. From the customer's point of view, the process took three days and twenty minutes. From the team's point of view, they only spent twenty minutes on it, which is why internal conversations about process speed so often talk past each other. The team is describing service time. The customer is experiencing total cycle time, which is service time plus waiting time.

Why the distinction matters

If you only measure service time, you will consistently underestimate how long a process actually takes, sometimes by a wide margin. Worse, you will misdiagnose where the problem is. A team that focuses entirely on making the twenty-minute assessment step faster, perhaps by simplifying the form or removing a redundant check, might shave off five minutes. That is a real improvement, but it barely dents a three-day total cycle time. The three days of waiting is where almost all the opportunity sits, and it has nothing to do with how efficiently the assessment itself is performed.

This is a common pattern across very different processes: invoice approval, employee onboarding, insurance underwriting, IT service requests. The actual work, once someone sits down to do it, is often quick. The waiting between handoffs is where the days accumulate. A process that looks efficient on a swimlane diagram, with short boxes and few steps, can still take a week in practice because of what happens in the white space between the boxes, not inside them.

Where waiting time actually comes from

Waiting time is not random. It tends to come from a small number of recurring causes, and recognizing them is the first step toward addressing them. Batching is one: a team that only processes a certain type of request once a day, or once a week, guarantees an average wait of half that interval before work even starts, regardless of how fast the work itself is. Uneven arrivals are another: if requests come in unevenly through the day or week but staffing is flat, cases pile up during peak periods and sit until capacity frees up, even though the team is not overloaded on average.

A third cause is prioritization rules that quietly deprioritize certain case types. If urgent cases are always handled first, routine cases can wait indefinitely during busy periods, not because anyone decided that was acceptable, but because nobody is tracking how long the deprioritized queue is actually growing. A fourth is simply unclear ownership: a case that does not have an obvious next owner tends to sit until someone notices it, and noticing is not guaranteed to happen quickly.

How to see it in your own process

Separating waiting time from service time requires looking at individual cases rather than averages. If you can trace a sample of real cases and record two things for each step, the time the case arrived at that step and the time someone actually started working on it, the gap between those two numbers is your waiting time for that step. Do this across a mix of case types, not just the straightforward ones, because complex or exception cases often carry disproportionately more waiting time, and they are usually the ones that get left out of quick manual reviews because they are harder to trace.

This is exactly the kind of question a discrete-event simulation is built to answer. Rather than tracing cases by hand, a simulation runs hundreds of cases through a modeled version of the process, respecting the arrival pattern, the routing rules, and the capacity at each step, and reports back how much of the total cycle time was spent waiting versus being worked on, step by step. That breakdown turns a vague sense that things take too long into a specific, defensible statement about where the time is actually going.

What to do once you know the split

Once waiting time is visible and separated from service time, the options for addressing it look different from the options for addressing slow work. Reducing service time usually means simplifying a task, removing an unnecessary check, or improving a tool. Reducing waiting time usually means changing how work arrives at a step, how often a queue is checked, how cases are prioritized, or how many people are available at the times demand actually peaks, rather than at the times average staffing happens to be scheduled.

It is worth resisting the instinct to jump straight to adding more people as the answer to a long queue. Sometimes the constraint is a scheduling pattern, like a step that is only checked twice a day, and fixing that costs nothing. Sometimes it is a batching decision made years ago for reasons that no longer apply. Testing a change to the arrival pattern or the checking frequency against a modeled baseline, before committing to a staffing increase, is usually the cheaper and faster path to finding out which lever actually moves the number.

How Processfix helps with this

Processfix builds a locked baseline of your process using a discrete-event Monte Carlo simulation run across hundreds of cases, and that baseline reports waiting time and service time separately at each step, not just a single blended cycle time figure. That makes it possible to see, before any change is made, exactly how much of the total time at a given step is queueing rather than work. From there, you can build an Improve scenario that changes a scheduling pattern, a routing rule, or a staffing level, and compare the resulting P50, P90, and P95 cycle times against the baseline to see whether the change actually reduces waiting time or just moves it somewhere else in the process.