Automation opportunity assessment

What is an automation opportunity assessment?

An automation opportunity assessment is the exercise of working out which work in your company is worth automating, and in what order. It happens before anyone builds anything, and it ends in a document rather than in software.

What it should produce is narrow: a ranked shortlist of processes, a number next to each one saying what it costs you today, and a person by name who owns the decision about it. A list of forty ideas with no numbers and no owners is a wish list. It reads well in a meeting and nothing happens afterwards.

Asking people versus measuring the systems

There are two ways to gather candidates, and each one makes a different kind of work visible. Run both, and know what each one hides.

Asking people

Interviews, a workshop per team, a form on the intranet. It costs nothing, and it is the only method that finds work which never touches a system: the phone call to the supplier, the folder on somebody's desk, the decision that lives in one person's head.

The bias is simple. People nominate what annoys them, not what costs the company most. A monthly reconciliation that takes one person five miserable hours gets named in every workshop. Three minutes of invoice typing, done nine hundred times a month by two people who are used to it, gets named by nobody. The second one is nine times bigger.

Measuring the systems

Process mining reads the event logs your ERP, CRM or ticketing system already writes, so it counts how often a case runs and how long each step took. Task mining records desktop actions, so it reaches the work in Excel, email and web portals that leaves no backend event behind.

The bias here is coverage. Process mining sees a step only if a system wrote a timestamp for it, so whatever gets settled by phone or in a shared drive is missing. Task mining sees only the people who were recorded, in the applications on the allowlist, during the weeks the recorder ran. Microsoft describes its own task mining as inviting colleagues to contribute recordings, which is an honest statement of the limit: the map is as complete as the group that agreed to record.

Asking people makes invisible work visible but gets its size wrong. Measuring the systems gets the size right, for the work that ran through a system it could see.

Three cheaper answers before you automate anything

Every candidate gets three questions before it gets a score, and all three are cheaper than building something.

1. Can you stop doing it? A weekly report nobody opens, a second approval on amounts under 250 euro, a control that exists because of an incident in 2018. Ask who reads the output and what they do differently because of it.

2. Can you simplify it? Six quote templates instead of one, four approval steps where two would hold, an exception list nobody ever pruned. A process with fewer paths is cheaper to automate later and cheaper to run in the meantime.

3. Can the upstream system do it right? Most manual repair work exists because something arrived wrong. If a third of your orders need retyping because those customers were never given portal access, giving them access removes the work instead of automating it.

Shell's finance operation uses an order worth copying: eliminate, simplify, standardise, and then automate. Their summary of it, published in an ACCA case study, says that RPA is not the solution to a badly designed process. Automating a broken process locks the mess in, because from then on it has code wrapped around it and changing anything costs a project.

What you score, and how to get each number honestly

• Volume per month. Count it in the source system, do not ask for it. Twelve months of row counts also show the seasonal peak, which is usually the month that hurts.

• Minutes per case. Measure it. Sit next to somebody for an hour, or read it off a task mining recording. People overestimate the work they hate and underestimate the work they do on autopilot, so the error runs both ways.

• Error and rework rate. Credit notes, corrected bookings and second emails to the same customer are countable, and rework minutes usually cost more per case than the original handling did.

• How stable the rules are. Could somebody else follow the decision if you wrote it down? When the answer starts with "it depends on the customer", the rules are not written down yet.

• How many systems the work crosses. Every extra system adds an integration, a login and something that breaks on the next update. Two is normal, five is a project.

• Whether an automatic check on the result exists. Can a machine tell whether the output is right? A three-way match against the order and the goods receipt is such a check. A customer complaint is not, and a process without a check needs a person reviewing output for as long as it runs.

• How the work changes anyway within a year. A new ERP, the last suppliers switching from scans to structured invoices, a customer portal that removes the input altogether. Do not automate what is being replaced.

UiPath keeps two axes apart in its Automation Hub assessment algorithm: ease of implementation, from process and application stability, data structure, variability, process length and the number of applications, and automation potential, from structured input, variability and how digital the process already is. Copy the two-axis shape. The percentages are theirs, not yours.

A worked example: four candidates at a technical wholesaler

A wholesaler with sixty staff runs an assessment. Four candidates reach the table: volume per month, measured minutes per case, and the product of the two.

• Monthly VAT reconciliation. 1 x 300 = 300 minutes a month. Everybody names this one. It lands at month end, it takes an afternoon and an evening, and the bookkeeper has raised it three years running.

• Supplier invoice matching. 950 x 3 = 2,850 minutes a month.

• Order intake by email. 420 x 7 = 2,940 minutes a month.

• Weekly stock report to four branches. 4 x 90 = 360 minutes a month.

On raw minutes, email orders lead, then invoice matching, then the stock report, with the VAT reconciliation last. Now apply the share of each process that can realistically run without a person.

• VAT reconciliation: the figures come from a spreadsheet one person maintains by hand and the work is mostly judgement. 30 per cent, and the accounting package is being replaced next year anyway. 300 x 0.30 = 90 minutes.

• Invoice matching: since the Belgian e-invoicing obligation took effect in January 2026 most invoices arrive as structured Peppol documents, the order number is on most of them, and a three-way match against the order and the goods receipt says automatically whether the result is right. The rest are scans from foreign suppliers. 80 per cent. 2,850 x 0.80 = 2,280 minutes.

• Email order intake: free text, no fixed layout, and a wrong line only surfaces when the customer phones. 35 per cent. 2,940 x 0.35 = 1,029 minutes.

• Stock report: a data pull with no judgement in it. 95 per cent. 360 x 0.95 = 342 minutes.

The ranking changes. Invoice matching is 38 hours a month, 456 a year. Email intake is roughly 17 hours a month, about 206 a year. The stock report is 5.7 hours a month, 68 a year. The VAT reconciliation, the loudest item in every workshop, is 1.5 hours a month, 18 hours a year, so even a perfect robot for it saves less than half a working week.

The VAT reconciliation still deserves an answer, but the answer is to fix the hand-maintained spreadsheet, which is the simplify question and not a build. And the stock report ranks third on benefit while being the cheapest thing on the list to build, so it can go first while the invoice work is being specified.

A saving on the payroll is not the same as an afternoon back

Those 456 hours are about a quarter of one person's working year in Belgium. Nobody leaves. What changes is that the two people in accounts payable stop working late in the last week of the month and start answering supplier queries the same day.

That is worth having and it is not money. UK Treasury guidance in the Green Book separates a cash-releasing benefit, which changes what an organisation spends or receives, from a non-cash-releasing benefit, which does not. Here, the three months of temp help hired every year to clear the invoice backlog is cash and the two permanent salaries are not. Put both on the shortlist, in separate columns, and never add them up. The same guidance says to adjust for optimism bias by raising cost estimates and lowering benefit estimates, so move your build estimate and your saving estimate the uncomfortable way before you present either one.

What to watch out for with an automation opportunity assessment

The most common mistake fits in one sentence. Companies pick the process everybody complains about instead of the process with the largest volume times minutes, because the complaint arrives with a person attached and the arithmetic does not. The second most common is automating a process nobody has fixed first, and that one costs more because it stays invisible for two years.

The other failure is the format. A shortlist an owner-manager can decide on in one meeting is one page, one line per candidate, five columns: the process, hours a year today, the share that can run without a person, the one thing that has to be fixed first, and the owner by name. Sort descending on hours times share. Underneath, list the candidates you rejected with one line each on why, because the rejected list is what stops the same idea returning every quarter.