How Monte Carlo Simulation Works for Business Processes

Ask someone how long an invoice approval usually takes, and you will get an answer like two days. Ask them how long it takes when the approver is out of office, or when the invoice needs a second sign-off because it crosses a threshold, and the honest answer becomes it depends, sometimes five days, sometimes same-day. Most real process steps behave this way: not as a fixed duration, but as a range shaped by circumstances that vary from case to case. Monte Carlo simulation is a technique built specifically to handle that kind of variability, rather than pretending it away with a single average.

The basic idea behind Monte Carlo simulation

The technique takes its name from the randomness involved in games of chance, and the core idea is straightforward. Instead of running a process model once with fixed values for every input, the model is run many times, and each time, the value used for something like task duration, arrival timing, or the outcome of a decision point is drawn from a realistic range rather than fixed at a single number. Run the model twice and you get two different stories. Run it five hundred times and you get a distribution: a picture of how the process behaves across a wide range of plausible circumstances, from the smooth, uneventful cases to the ones that hit every possible delay.

This matters because a business process is rarely deterministic. The same claims process handles a straightforward claim in a day and a complicated one with three exceptions in three weeks. A single-run model, using an assumed average for everything, cannot capture that spread. A Monte Carlo simulation is built precisely to capture it, by treating variation as the normal state of a process rather than as noise to be averaged away.

What actually gets varied across the runs

A handful of elements typically carry the variation in a process simulation. Arrival patterns vary, reflecting the fact that cases do not arrive at a perfectly even rate throughout the day or week. Task durations vary within a realistic range for each step, reflecting the difference between a routine case and a complicated one. Decision outcomes vary, so that an approval step that is granted on the first pass most of the time but escalated occasionally is modeled as a probability rather than a fixed path. Resource availability can vary too, reflecting the fact that a queue behaves differently when one of two approvers is on leave.

• How and when cases arrive into the process
• How long each task takes, within a realistic range for that step
• Which branch a decision point takes, based on how often each outcome typically occurs
• How much capacity is available at each resource across the run

Why the simulation runs across hundreds of cases

Running a model only a handful of times risks drawing a conclusion from an unrepresentative sample, in the same way that judging a process from three anecdotal cases in a meeting risks the same thing. Running it across hundreds of simulated cases smooths out that risk. It allows the rare but real scenario, the case that hits an exception, gets escalated, and gets sent back for rework, to appear in the results at roughly the rate it would appear in reality, rather than being either overrepresented by an unlucky small sample or invisible because it was left out of a single walkthrough. The larger the number of simulated cases, the more the resulting distribution of outcomes reflects the true range of behavior the process is likely to produce.

Turning hundreds of runs into a decision

The output of a Monte Carlo process simulation is not a single number, and treating it as one throws away most of its value. The useful output is a distribution: the range of cycle times observed across all the runs, the proportion of cases that took longer than a target threshold, the utilization level at each resource across the full spread of scenarios, and where queues tended to build up most consistently. From that distribution, a team can read off specific reference points, such as the cycle time that half of cases beat and the cycle time that only a small fraction of cases exceed, which gives a much more honest picture of process risk than a single averaged figure ever could.

This distribution also becomes the basis for comparison. Once a baseline distribution exists for the process as it runs today, a proposed change, whether that is added capacity at a bottleneck, a simplified approval path, or an AI-assisted step, can be modeled as its own scenario and run the same number of times. Comparing the two distributions, rather than comparing two single numbers, shows whether a change genuinely narrows the spread and improves the typical and slower cases, or whether it only moves the average while leaving the worst outcomes just as bad.

The technique does not remove the need for good assumptions

How Processfix applies this

Processfix runs a discrete-event Monte Carlo simulation over an editable model of a process, using clarifying questions to establish realistic ranges for task durations, arrival patterns, and decision outcomes with the people who actually run the process. The simulation runs across hundreds of cases to produce a locked baseline, and any Improve or Add AI scenario built afterward is run the same way, so that a comparison of P50, P90, and P95 cycle time, throughput, and utilization between the baseline and a proposed scenario is a like-for-like comparison rather than a single optimistic estimate against another single optimistic estimate.