How to Decide Whether a Business Process Is Worth Automating

Most automation projects that disappoint were not bad builds. They were good builds aimed at the wrong process: one that ran twice a month, one whose rules changed every quarter, or one where the real work lived in exceptions nobody mentioned during scoping.

A process should earn its place on the automation list before anyone writes code. This is the scoring method we use in discovery, the rule that overrides the score, the costs that usually get left out, and the arithmetic that turns all of it into a yes or a no.

Score the process on four factors

Rate each candidate from 1 to 5 on four factors, then multiply the scores together. Multiplying rather than adding matters: a process that scores 1 on any factor should sink, no matter how well it does elsewhere.

• Frequency. 1 = a few times a year, 3 = weekly, 5 = many times a day.
• Time per run. 1 = under a minute, 3 = 5 to 15 minutes, 5 = an hour or more of hands-on work.
• Error cost. 1 = a typo nobody notices, 3 = rework and an awkward customer email, 5 = a wrong shipment, a missed filing deadline or a refund.
• Rule stability. 1 = the steps change monthly or depend on who is doing them, 3 = stable with occasional policy changes, 5 = the same steps for years.

The maximum score is 625. As a rule of thumb, anything under about 40 is rarely worth a dedicated build. Between 40 and 150, look for a partial win, such as automating one painful step rather than the whole flow. Above 150, the process is a real candidate and deserves the cost analysis below.

Score with the people who do the work

Managers tend to underestimate frequency and overestimate stability. The person who processes the invoices knows that “about 20 a week” is really 45 in month-end week, and that the supplier portal changed its export format twice last year. Score each process with that person in the room, and time a few real runs instead of relying on estimates.

The process must be stable first

Rule stability is the one factor that can veto everything else. Automating a process that is still being redesigned freezes today’s confusion into software, and every later change becomes a change request instead of a conversation.

Signs a process is not ready:

• Two people describe the steps differently, and both are “right.”
• Nobody can say who owns the process or who approves changes to it.
• A large share of cases are handled by “just ask Sarah.”
• The business is about to change a related system, such as a new CRM or accounting package.
• The rules exist mainly in email threads and people’s heads.

If two or more of these apply, the first project is documentation, not automation. Write the steps down, agree on them, run the process that way for a few weeks, and then score it again. That work is rarely wasted: a clearly documented process often turns out to have a step that can simply be removed.

Count the hidden costs

The build is the visible cost. The ones that decide whether the project pays back usually come later.

• Exception handling. Someone still has to deal with the cases the automation cannot handle, and they need a clear queue to work from rather than a silent failure.
• Maintenance. APIs change, vendors rename fields, logins expire. Budget a few hours a month for a typical integration, more if it touches several third-party systems.
• Monitoring. Somebody needs to notice when the automation stops running. A workflow that fails quietly for two weeks can cost more than it ever saved.
• Running costs. Hosting, automation platform subscriptions, and per-call fees for AI or OCR services. These are usually small but recur every month.
• Change management. Staff need to trust the output, know where exceptions land, and stop keeping their own spreadsheet “just in case.”

Watch the exception ratio

The single most useful number in scoping is the share of cases that do not follow the standard path. If 90% of cases are routine, automation handles the bulk and people focus on the rest. If 40% are exceptions, much of the original manual work remains, and you have added a system to maintain on top of it. Pull a sample of 50 recent cases and count before you commit.

Run the ROI arithmetic, step by step

Here is a worked example. It is hypothetical, and the numbers are assumptions chosen to show the method, not quotes or benchmarks.

Example: a 12-person logistics firm receives delivery notes as PDFs and photos, and a coordinator re-keys each one into the dispatch system.

1. Volume. 60 notes a day across 22 working days is 1,320 notes a month.
2. Current time cost. At 4 minutes per note, that is 5,280 minutes, or 88 hours a month. At an assumed loaded staff cost of $30 an hour, that is $2,640.
3. Current error cost. If 2% of notes are mis-keyed, that is about 26 errors a month. At an assumed $40 each to fix (a phone call, a corrected invoice, sometimes a re-delivery), that is roughly $1,040.
4. Automated share. Suppose 85% of notes are extracted and entered without human touch: 1,122 notes. The remaining 198 are still keyed by hand.
5. Time saved. 1,122 notes at 4 minutes is about 75 hours, or $2,244 a month.
6. Errors avoided. If errors fall from 26 to 5 a month, that saves 21 at $40, or $840.
7. Gross monthly benefit. $2,244 + $840 = $3,084.
8. Recurring costs. Assume $150 a month for hosting and extraction fees and $400 a month for maintenance and monitoring. Net benefit: $3,084 − $550 = $2,534 a month.
9. Payback. If the build costs $15,000 (again, an assumed figure for the arithmetic), payback is $15,000 ÷ $2,534, or just under 6 months.

Test the sensitivity

Now halve the volume to 30 notes a day. Gross benefit falls to about $1,542, net benefit to about $992, and payback stretches to roughly 15 months. Same process, same build, very different answer. Run the numbers at your low-season volume and with a worse exception rate. If the project still pays back within a period you are comfortable with, it is a sound bet.

Processes that look worthwhile but usually are not

• Rare but painful. An annual reconciliation that takes three miserable days is memorable, but 3 days a year rarely justifies a build. A good checklist often does more.
• Judgment-heavy work. Pricing a custom construction job or negotiating with a supplier involves decisions that are hard to specify. Automating data gathering around it can help, but the decision itself stays with a person.
• Steps that should not exist. Before automating a weekly report, check that anyone reads it. Removing a step is cheaper than automating it.
• One-person processes. If a process is reliable only because one experienced person does it, capture what they know first. Otherwise you automate the visible steps and miss the judgment that made it work.

Next step: score your top five

List the five manual processes your team complains about most. For one week, have the people who run them record how often each happens and how long it takes. Score each on frequency, time, error cost and stability, apply the stability veto, and run the ROI arithmetic on the top two using your own staff costs and volumes.

That exercise usually takes a few hours and produces a short, defensible list. If you would like a second opinion on the numbers, or help turning the top candidate into a working system, see our business automation service.