Business Process Automation: What to Measure Before the First Workflow

Business process automation (BPA) is the use of software to run repeatable, multistep business processes, such as invoice approval, new account setup, or claims intake, across the systems and people involved. Before an operations team buys it, one thing should already exist: a measured baseline of the work the automation is meant to take on. Without that baseline, nobody can check the business case before signing or prove the saving afterwards.

Most business process automation guides agree on the first step, “identify the processes to automate”, and then skip straight to mapping and tool selection. This article covers the part in between: which numbers to measure, why the saving from a workflow project so often fails to show up, and what measuring first has looked like on real back-office projects.

Quick Answer

Business process automation is software that runs a multistep business process across systems and people. Before a workflow project, measure hands-on minutes per item, how much of the work happens outside the system of record, the share of items that follow the standard path, touches and rework, how the hours are spread across people, and today’s cost per item.

What Is Business Process Automation?

IBM defines business process automation as “a strategy that uses software to” automate complex and repetitive business processes. Red Hat’s definition is tighter: “the use of software to automate repeatable, multistep business transactions.” Both stress the same thing. A BPA project automates a whole process that crosses several systems and teams, which makes it a bigger undertaking than a single scripted task.

Four terms get used almost interchangeably in vendor material, and they are worth separating before any budget is committed.

IBM places RPA “under the umbrella of BPA” and notes that, “Due to its narrower focus, RPA can often be implemented more quickly than broader BPA initiatives.” In practice, most business process automation software combines workflow routing, integrations, and some RPA. When the process also involves reading documents or making bounded judgment calls, the category becomes intelligent automation, which adds AI to the mix. We cover that step in intelligent automation readiness for operations.

Why Business Process Automation Software Gets Bought Before the Work Is Measured

The sequence in most programs is familiar. A process gets nominated because it is visibly painful, a platform gets demonstrated against it, and a pilot proves that the software can do what the demo showed. Measurement, if it happens at all, is a walkthrough of the documented procedure with the process owner.

That order has a long record of disappointing. In its paper Get ready for robots, EY reported that it had seen “as many as 30 to 50% of initial RPA projects fail”, and was clear that this “isn’t a reflection of the technology.” One of the causes it listed is familiar to anyone who has sat in a steering committee: programs that “cannot answer simple questions from the Board about ‘where are we going to target RPA, how much will it cost and what is the return?'”

Those are measurement questions. They can only be answered from a baseline of the work as it is done today.

Survey data suggests that baseline is usually missing. In Deloitte’s 2020 intelligent automation survey, only 20% of respondents were using process mining and 33% were using process monitoring, the two tool categories built to show how processes actually run. Deloitte also found that organizations still in the piloting stage “are more likely to automate current processes, with limited change.” In other words, the process gets automated in the shape it already has.

The written procedure and the performed process are rarely the same thing. The procedure describes the standard path. The people doing the work handle everything else too: the missing field, the duplicate request, the customer who replied to the wrong email thread. A workflow built from the procedure automates the part of the job that was already the easy part.

Six Numbers to Measure Before a Workflow Automation Project

A workflow automation business case rests on a small set of numbers. Each can be estimated in a workshop, and each is usually wrong when estimated that way. Measure them in the teams in scope, at the level of what people actually do during the day, over enough weeks to include a month-end or a volume spike.

1. Hands-on minutes per item

This is the time a person spends working on an item, as distinct from the time the item spends waiting. A loan file that takes six days to close may need only 40 minutes of hands-on work across four people. The business case for automating it depends almost entirely on those 40 minutes, and a system log cannot provide them. Our comparison of process mining and workforce intelligence explains why event timestamps miss this number.

2. How much of the work happens outside the system of record

Most workflow tools are sold on their integrations with the core system. The work that hurts often sits somewhere else: shared mailboxes, spreadsheets, supplier portals, and chat. Red Hat notes that when workflows are “managed ad hoc,” they “typically involve multiple email threads, documents, and handoffs.” If half of the hands-on time sits in email, a workflow that only watches the core system will leave half the work where it was.

3. The share of items that follow the standard path

Every process has a standard path and a set of detours. Measure what share of items take the standard path from start to finish, and how much time the detours absorb. A process where 90% of items follow the standard path is an automation candidate. A process where 40% do is often a redesign candidate first, and automating it as is locks the detours in place.

4. Touches and rework per item

Count how many people handle an item, and how often an item returns to someone who has already worked on it. Rework is where much of the recoverable time hides, and it rarely appears in a process owner’s description, because each return feels like a one-off. When items come back often, the fix may be a validation rule at intake rather than a new workflow downstream.

5. How the hours are spread across people

This is the number most business cases skip, and the next section explains why it matters most. For each activity the workflow would take over, find out how many people do it and what share of each person’s day it fills. Twenty hours a week concentrated in one role is a very different saving from twenty hours spread across 40 people at half an hour each.

6. Today’s cost and cycle time per item

This is the baseline the vendor’s business case should be checked against now, and the one its results should be measured against later. Record cost per item, cycle time, and error rate for the same period you measured everything else. Without it, the post-implementation review compares the new process to a memory. Our guide to measuring AI ROI in operations covers what to do with the numbers after go-live.

Consider an illustrative example (a composite, not a client result). Dana runs claims operations for a regional insurer, and her team has shortlisted first notice of loss intake for a workflow platform. The procedure has eleven steps, all inside the claims system, and the vendor’s business case assumes 18 minutes saved per claim.

Measured over six weeks, intake staff spend about a third of their hands-on time in a shared mailbox, chasing photos and police reports that arrived separately from the claim. The platform would route the claim well, but the photos and reports would still come in by email. Dana changes the scope before signing: intake of attachments first, routing second.

Once the six numbers exist, choosing between candidate processes becomes a ranking exercise. Our guides on how to know what to automate in operations and scoring processes in a workforce automation analysis take it from there. If you already have a platform shortlist and none of these numbers, book a 30-minute strategy call and we will look at which ones your business case depends on.

The Saving That Spreads Too Thin to Bank

Here is the failure that the fifth number predicts. A workflow project removes 25 minutes a day from each of 40 people. On paper that is more than 16 hours of capacity a day, or roughly two full-time roles.

In practice, nobody is freed. Each person gets back a scattered 25 minutes, which gets absorbed by the rest of their queue, a longer lunch, or better service on the next item.

EY described the same effect in its paper. Unless a structured reorganization is planned as part of the project, it wrote, people “quickly ‘drift off’ to perform other work”, and “it means that the benefits are not fully realized and subsequent phases are not approved.” The automation works, but the saving never shows up in a budget, so the second phase loses its funding.

The way to avoid this is to decide, before the project starts, what happens to the freed time:

• Absorb forecast volume growth without new hires, and record the hiring you did not do
• Consolidate the activity into fewer roles, so the freed time is whole days rather than fragments
• Redeploy the time to a named backlog, such as quality reviews or aged items, with its own measure
• Reduce contractor or overtime spend in the teams affected, where that spend exists today

Each option needs the same input: who does the work now, and how much of their day it fills. Without that, a board asking where the saving went gets an answer about adoption rates instead of money.

Consider a second illustrative composite. An accounts payable team of 30 automates three-way invoice matching and celebrates a 70% cut in matching time.

Six months later, headcount and overtime are unchanged, and the CFO asks why. The matching work had been spread across every clerk at 20 to 30 minutes a day, so the saving came back as fragments nobody could redeploy. A baseline showing that spread would have pointed to consolidating the remaining exception handling into a small team before go-live.

What Measuring First Looked Like on Two Back-Office Projects

The principle is older than the current wave of business process automation software. Before our consultants built workflow tooling for clients, they measured the work by hand.

In Nationwide’s back-office processing operation, the team conducted more than 10,000 side-by-side observations across two sites to identify best practices and streamline workflows. It also implemented a Workload Distribution Tool that replaced 84 manual reports with electronic work tickets, “enabling priority-based routing and real-time workload balancing.” The published result was a 22% reduction in unit costs, eliminated overtime, and $1.6M in savings.

In a payments company’s client services department, the team began by conducting 868 side-by-side observations “to gain an accurate understanding of key activities and baseline processes.” More than 90% of customer requests arrived by email to individual mailboxes, which made the work impossible to track for quality, productivity, or workload balance. The fix was a custom case management tool with a central inbox and request tracking, and the project delivered $1.2M in savings, with hard-dollar savings in 23 weeks.

In both projects, a large study of the work as people actually did it sat underneath the tooling. Side-by-side observation is slow and expensive, which is the main reason most organizations skip it, and it is the step the Ground Truth AI² Platform was built to automate.

Where Summit Trails Fits

Our part of a business process automation program ends where the platform decision begins. We measure the work, and your team takes the numbers into the vendor conversation. We do not recommend specific vendors, build the workflows, or run the rollout.

The Ground Truth AI² Platform replaces the side-by-side observation described above. A lightweight desktop client captures the screen region around each click, between 500 and 3,000 captures per person per day, and never records keystrokes or the full screen. Vision AI then classifies each capture at the activity level, so the record reads “matching a remittance to an open invoice” rather than “six hours in the ERP,” and each activity carries an automation score.

You can see how the capture, classify, and insight method works and what the output looks like.

A first engagement covers at least 50 employees in the operations area in question, over a fixed 90 days. Initial findings arrive around weeks three to four. The Ground Truth AI² Report at the end carries the activity baseline, an AI replacement assessment, and a prioritized deployment roadmap, which between them supply most of the six numbers for every person in scope.

Wendy Kinney, who has more than 20 years in workforce operations with organizations including Nationwide, AT&T, and Boeing, leads the operational interpretation. The customer owns the data, and the platform page sets out the encryption and privacy architecture. Pricing is a base fee plus a per-employee cost, scoped on a call.

A small, contained process rarely justifies any of this. If the work sits in one team and one system, and no staffing decision hangs on the result, a few weeks of careful sampling by the process owner will usually do. Measurement at this depth pays off when a workflow crosses several teams, when a large share of the work lives in email and spreadsheets, or when the business case will be challenged by a CFO or a board.

Frequently Asked Questions

What is business process automation in simple terms?

Business process automation is software that runs a business process with several steps, such as approving an invoice or opening a new account, so that routing, data entry, and handoffs happen automatically instead of by hand. It usually connects several systems and moves work between them and the people who still handle exceptions.

What is the difference between business process automation and RPA?

RPA automates individual tasks at the screen level by copying what a person does in an application. Business process automation covers the whole process, including routing, approvals, integrations, and the RPA steps inside it. IBM describes RPA as falling under the umbrella of BPA.

Is workflow automation the same as business process automation?

Not quite. Workflow automation handles the flow of work between people and steps: assignments, approvals, deadlines, and escalations. Business process automation is broader and usually includes workflow automation plus the integrations and task automation that remove manual work inside each step.

What are examples of business process automation in operations?

Common examples include invoice matching and approval in accounts payable, first notice of loss intake in insurance claims, new account setup in banking, work order routing in utilities, and purchase order creation when inventory falls below a threshold. Each one crosses several systems and several teams.

How do you measure the ROI of business process automation?

Record a baseline before the project: hands-on minutes per item, cost per item, cycle time, error rate, and how the affected hours are spread across people. Measure the same things after go-live, and track where the freed time went. ROI that cannot be traced to budget, avoided hiring, or a named backlog usually was not realized.

How long should you measure a process before automating it?

Long enough to see a normal cycle, including peaks. For most back-office processes that means several weeks and at least one month-end or seasonal spike. A single week tends to catch either an unusually quiet period or an unusually busy one, and the business case inherits the error.

Before the Workflow Contract Is Signed

Business process automation delivers when it is aimed at work that has been measured and when someone has decided in advance where the freed time goes. The software will do what the demo showed. Whether that changes your cost per item depends on six numbers that most teams estimate in a workshop and never check.

If a workflow automation project is about to be approved in your operation, book a strategy call. In 30 minutes we will go through the process you have in mind, the numbers its business case rests on, and how you could measure them before the contract is signed.