Workflow analytics: an introduction for operations leaders
If you have spent time in operations in the last few years, you have probably heard of process mining. The basic idea is compelling: connect to your business systems, extract the event logs that record when transactions changed state, and reconstruct what your processes actually look like from the data. No workshops, no swimlane diagrams that reflect how someone thinks the process works. Actual data.
Workflow analytics extends that idea to cover more of the work that happens in real operations. Most operations processes do not live entirely inside a single system. They span email, project management tools, CRMs, ERPs, finance systems, and various other specialised tools. The event log for a purchase approval might involve an ERP transaction, two email threads, a Slack message, and a task in a project management system. Process mining built on ERP data captures the ERP events. Workflow analytics captures the full picture.
This article explains what workflow analytics actually is and what operations leaders can practically do with it.
What workflow analytics measures
Workflow analytics measures the movement of work through a process, using timestamped event data from all the systems the process touches. The output is a quantitative map of how work actually moves: what states it passes through, how long it spends in each state, what percentage of instances follow each path, and where the exceptions and rework occur.
The inputs are event logs. Not reports, not summaries, not screenshots. Logs that record "transaction X entered state Y at timestamp Z." Every time an item is assigned, approved, rejected, returned, escalated, or completed, that event is recorded with a timestamp. Workflow analytics uses those logs to reconstruct the actual process at the individual-transaction level, then aggregates across all transactions to produce the pattern-level view.
The measures that matter for operations decisions are: cycle time distribution (not just the average, but the full distribution including the long tail), active processing time versus idle time within each step, rework rate and rework drivers, handoff duration at each transition point, and path distribution (how many distinct paths exist through the process, and what share of volume follows each).
How it differs from traditional process documentation
Traditional process documentation is normative: it describes how the process should work. Workflow analytics is descriptive: it describes how the process does work. These are almost never the same thing in a process that has been running for more than two years.
The gap between documented and actual process is not a criticism of the people who documented it. Processes accumulate variance over time as teams adapt to new circumstances, work around system limitations, and respond to changing volume patterns. The documentation captures a moment in time. The workflow data captures the current reality.
For automation planning, this distinction is critical. You cannot build reliable automation against a documented process if the automation will encounter the actual process at runtime. The exceptions that automation cannot handle are typically the extra steps, informal workarounds, and path variations that appear in the workflow data but not in the documentation. Building automation from workflow data rather than documentation means you start from what the process actually does, which is the only starting point that produces reliable savings estimates.
What operations leaders can do with it
There are three practical uses for workflow analytics in an operations context.
First, baseline costing. Before you can make a credible case for automating a process, you need to know what the process currently costs. Not an estimate from interviews or time studies, but a calculation from actual process data: transaction volume multiplied by average labour time per transaction multiplied by loaded cost per hour. Workflow analytics provides the labour time component from actual event log data, which is the component that estimates get most wrong.
Second, identifying automation candidates. Not every process is worth automating. The processes worth automating have specific structural characteristics: high volume, repetitive path distribution, long idle time relative to active processing time, and rule-based decision logic at each step. Workflow analytics tells you which of your processes have these characteristics and which do not, without requiring you to manually review each one.
Third, sizing the opportunity. Once you have identified a candidate process, workflow analytics tells you how much of the current cost is addressable by automation. If 70% of a process's cycle time is in active-processing steps that require human judgment, automation will not reduce those. If 70% is in idle time and data-transfer steps, those are strong automation candidates. Knowing which portion is addressable before you build the business case is what separates automation proposals that get funded from ones that do not.
What workflow analytics is not
Workflow analytics is not a business intelligence tool. It does not replace your reporting dashboards or your financial forecasting. It operates on event logs, not on transactional summary data, and it answers questions about process mechanics, not about business outcomes. You still need BI to understand what the business produced. Workflow analytics tells you how it was produced and where the friction is.
It is also not an automation execution tool. Fluency identifies and quantifies automation opportunities; it does not build the automations. The output of a workflow analytics analysis is a prioritised, quantified list of process improvement opportunities with defensible ROI estimates. What you do with that list, which tools you use to implement the automations, and how you sequence the programme is the next stage. Workflow analytics is the planning layer.
A realistic starting point
The most common question we hear from operations leaders starting out with workflow analytics is: which process should we connect first? The answer is: whichever one has the clearest combination of known pain, high volume, and accessible event log data.
Known pain means someone in the organisation already believes this process is costing more than it should, or taking longer than it should. High volume means there are enough transactions to produce statistically reliable patterns, typically at least 200 to 300 transactions per analysis period. Accessible event log data means the primary systems the process touches already record timestamped events and those events can be connected to a workflow analytics tool without a large data engineering effort.
Starting there gives you the fastest path to a result that is credible enough to build a business case from. Once you have one process mapped and costed from data, the approach is proven and the next process is easier to justify. That is the practical starting point for most teams: one process, one data source, one credible baseline. Build from there.