Business process automation: score it before you build it

Most first automation projects fail before anyone builds a workflow. The process gets chosen in a meeting by whoever complained loudest, and six weeks later nobody can say whether anything improved. Business process automation works better as arithmetic than as enthusiasm. Put a number on what a process costs you this year, put a rough number on what it costs to change it, and the first project picks itself in about twenty minutes. No vendor demo required.

That is the whole argument. Everything below is the detail: how to score candidates, which processes are ready, which ones to leave alone, and how to keep the first build small enough that it actually ships.

A broken process breaks faster when you automate it

Take an approval that should have had a second pair of eyes. Automate it as-is and you will find out at month end, at volume, with a clean audit trail pointing back at the workflow.

The manual version was slower. That slowness was doing a job. It gave someone a chance to notice. Strip it out and you have removed the last checkpoint without replacing it.

So automation does not fix a process. It multiplies whatever is already there. If the steps are sound you get the same result in a fraction of the time. If they are not, you get the wrong result faster and a team that stops trusting the system. The first project should be the one where the multiplier is safe.

How to score business process automation candidates

Four inputs, one guess, and a calculator.

1. Hours per week the process eats across everyone who touches it. Count the waiting too, not only the typing.
2. Number of people involved. A two-minute task that five people queue behind is a bigger problem than it looks.
3. Loaded hourly cost. Salary plus overhead, not gross pay. Round it, this is a ranking exercise, not accounting.
4. Implementation risk, scored 1 to 5. One clean input and one clean output is a 1. Three systems that disagree with each other about the same client name is a 5.

Then run this:

annual cost = hours per week x people x loaded hourly rate x 48 weeks
priority    = annual cost / implementation risk

Forty-eight weeks, not fifty-two. Nobody works every week of the year, and using the real figure keeps the comparison honest.

A walkthrough with invented numbers

Here is a hypothetical firm, made up for the exercise. Forty people, professional services, nothing automated beyond a few email rules. The figures illustrate the method. They are not a forecast for anyone.

• Quote assembly: 6 hours a week, 3 estimators, 45 an hour, risk 2. That is 6 x 3 x 45 x 48, giving 38,880 a year and a priority of 19,440.
• Invoice status chasing: 11 hours a week, 2 people, 30 an hour, risk 3. 31,680 a year, priority 10,560.
• Weekly leadership report: 4 hours, 1 person, 60 an hour, risk 1. 11,520 a year, priority 11,520.
• New client onboarding: 9 hours across 4 people at 35 an hour, risk 4. 60,480 a year, priority 15,120.

Onboarding burns the most raw hours. Quote assembly wins on priority because there is far less that can go wrong: one template, one price list, one output. And the process everyone grumbles about, invoice chasing, finishes bottom of the four.

That happens a lot. The loudest process is rarely the costliest one. Complaints measure frustration rather than frequency, and the frustration usually comes from whoever has to explain the delay to a customer.

The score ranks candidates. It does not make the decision. Two other things matter. Can you measure the current cost at all? If not, measure for a week before you build anything. And does somebody own the process well enough to sign off on a new version?

Five signals a process is ready to automate

• Two people describing the steps would produce roughly the same list. Not identical wording, the same order and the same handoffs.
• The input arrives in a predictable shape: a form, an email with a fixed subject line, a record created in one system.
• You could check the output by eye in under a minute. If verification is harder than doing the work, the automation is premature.
• Volume is steady rather than spiky. A trickle one week and a flood the next is harder to justify than an even fifty a week.
• Somebody already owns it. Unowned processes attract automation projects that run forever and get used by nobody.

Processes to leave alone for now

• Anything that needs judgement on every single instance. If a person would say "it depends" out loud, a workflow will guess badly and guess confidently.
• Anything redesigned every quarter. You would rebuild it as often as the process changes, and you would lose that race.
• Anything under a few hours a month in total. The implementation risk outweighs the saving. Do it by hand and spend the budget somewhere else.
• Anything sitting in the middle of an ownership dispute. An automation project in the middle of a turf war becomes the turf war.
• Anything where a mistake is expensive to reverse: payments to new payees, contract language, public statements. Those can come later, with approvals attached. Not first.

Most workflow automation services will start with whichever process you name, because that is what the brief says. Which is exactly why the scoring matters. If you are comparing business automation services, ask what they would refuse to automate first. The answer tells you more than the proposal does.

Keep the first project small enough to finish

Two to four weeks, one trigger, one output, one owner. If the first version needs two systems integrated before it does anything useful, pick a different process.

A few rules keep it finishable:

• Ship the boring version first. Create the record, notify the owner, log what happened. Add drafting or summarising later, once the plumbing is proven. The plumbing is what breaks.
• Keep a human checkpoint wherever the cost of a bad run is high. An approval step is not a failure of ambition.
• Measure before and after with the same method. One number, the same definition, both written down before you start so the goalposts cannot move afterwards.
• Leave the whole thing somewhere a person can read it. A named workflow doing one job can be debugged at 8am. A clever one cannot.

This is the ground workflow engineering covers in detail: mapping the process as it actually runs, then replacing the deterministic parts and leaving the judgement where it belongs. AI fits in the same frame, and AI and automation is worth reading before you decide the first project should involve a model at all. Often it should not. AI automation services tend to sell the exciting layer on top, which is worth nothing while the record still gets typed in by hand.

Then pick. Two to four weeks, one number to beat, and a process you can describe on a single page. If you would rather walk your shortlist with someone, book a discovery call. If you are still gathering candidates, start with the earlier piece on where to start with automation.

Frequently asked questions

How long should a first automation project take?

Two to four weeks of build, plus about a week of measurement on either side. If the estimate comes back longer than that, the scope is wrong rather than the timeline.

Do we need AI to automate a process?

No. Most of the value in a first project comes from rules, triggers and a database. A model earns its place when the input is unstructured text and a person would otherwise read every message. Get there after the simple version runs.

What if two processes score the same?

Break the tie with reversibility. Pick the one where a bad day is annoying rather than expensive. Then pick the one with the owner you can reach fastest, because sign-off speed decides whether a project ever finishes.

Can we automate a process that is still broken?

Not usefully. Fix the steps first, by hand if that is what it takes, and automate afterwards. Otherwise you are building a faster version of a problem you have not defined yet.