Building the business case for automating a process

A credible automation business case rests on five measures: cycle time, handling time, rework, capacity recovered and payback. Most automation proposals skip the first four and jump to the fifth, which is why finance teams discount them. An operations or IT leader who baselines the process honestly before anything is built will have a case that survives review, and a way to prove afterwards that the change worked.

The problem with most automation cases is that they are written backwards. A tool is chosen, a vendor supplies a savings estimate, and the estimate is reverse-engineered into a spreadsheet. Nobody measured how the work runs today, so nobody can say what changed. When the project is reviewed a year later, the only evidence is that the tool is in use.

Start instead with the process and five measures.

Cycle time is how long a single item takes from the moment it starts to the moment it is finished: a request raised to a request fulfilled, an invoice received to an invoice paid, an application submitted to a decision. It is the measure customers and employees feel. It is usually dominated by waiting, not working, which is why automation that removes hand-offs and waits can shorten it far more than automation that makes individual tasks faster.

Handling time is the effort people spend on each item: reading it, keying it, checking it, forwarding it, answering questions about it. It is the measure that becomes capacity. Estimate it by sampling. Ask the people who do the work to log a representative batch of items for a week or two, or time a handful of items end to end with them. Do not rely on memory; people consistently underestimate the small tasks that make up most of the effort.

Rework is the share of items that have to be touched again because something was missing, wrong or rejected. It is often the largest hidden cost in a process, because every returned item repeats part of the handling time and adds to the cycle time. Count it from the records you already have: tickets reopened, forms returned, payments reversed, entries corrected.

Capacity recovered is what the first three add up to. In plain terms, it is the volume of items in a period multiplied by the handling time saved on each, plus the handling time avoided by the rework that no longer happens. Express it in hours per month, not in headcount. Hours are honest; headcount implies a decision nobody has made.

Payback compares the one-time cost of making the change and the ongoing cost of running it against the value of what changed, over a period the organization cares about. The value side should include capacity recovered, but it should not stop there.

Capacity recovered is not money saved until someone decides what the recovered hours will be used for. This is the point where many business cases lose credibility. If the recovered time is absorbed into the day, the process is better but the budget is unchanged. That can still be the right outcome. A team that stops re-keying data may finally have time for the customer follow-up that was always slipping, or may absorb growth without adding people. Say which it is. A case that states "this frees the equivalent of part of a role, which we will use to handle next year's growth in volume" is more believable than one that counts salaries that will still be paid.

Some of the most important value does not show up as hours at all. Automation can reduce error rates in work where an error is expensive: a payment to the wrong account, a missed renewal, an access right that is never revoked. It can produce an audit trail where there was none. It can shorten the time customers wait for an answer. Name these benefits, measure the ones you can, and describe the others plainly without inventing a number. A reviewer will accept "we cannot price the audit trail, but we will have one" far more readily than a precise figure with no source.

To build the baseline, two to four weeks of real data is usually enough for a process with steady volume. Pull the item count and timestamps from whatever system records the work, even if that system is a shared mailbox or a spreadsheet. Sample handling time with the people who do it. Count rework from corrections and returns. Write down the assumptions: which items were included, which were excluded and why, and what season of the year the sample covers.

Then look at the process before the tool. The baseline often reveals that the biggest delay is an approval nobody needs, or that most rework comes from one missing field at intake. Those fixes may cost almost nothing and may change the business case entirely. Sometimes the honest answer is that the process should be simplified first and automated later, or not at all because the volume does not justify it.

When automation is justified, the case should describe the future process as well as the technology: which steps disappear, which become automatic, which stay with a person because they need judgment. That description is what lets finance and operations agree on what is being bought.

Agree the baseline and the measures before the build starts, and write them into the scope. This single step does more for the credibility of automation than any savings model. It means the team delivering the change and the team receiving it have agreed, in writing, what success looks like and how it will be checked. It also protects the project from scope drift, because any change can be tested against the measures everyone signed up to.

After go-live, measure again once the process has run at normal volume for long enough to be representative, commonly one to three months. Compare the same five measures against the baseline, using the same method. Where the results fall short, find out why: an exception path that still runs by hand, a step people are working around, a volume assumption that was wrong. That is where the next round of improvement comes from.

This is how CnergyPro approaches automation economics across the delivery model. Assess sets the baseline and finds where time and rework really go. Architect designs the future process and the business case together, so the numbers describe a specific change rather than a tool. Implement builds and stabilizes it. Optimize measures the result against the baseline and uses the gap to decide what to improve next.

A good business case is not a sales document. It is the agreement that lets an organization decide with confidence, and then know whether it was right.

CnergyPro helps organizations improve critical business processes, then configures, integrates, builds and optimizes the technology that makes the better process operational, with the measures agreed before the work begins. If a process is costing more time than it should and you need the case to prove it, tell us what's not working.