The problem isn't a lack of ideas. It's an excess of them.
When a COO begins exploring AI automation, the first obstacle is rarely technical. It's the list. Financial reporting, reconciliations, vendor follow-up, client onboarding, inventory control, management reporting. Everything feels urgent. Everything looks like a candidate.
With an unlimited budget, you could tackle everything in parallel. But in a company of 50 to 200 people, the budget isn't unlimited, the technology team isn't either, and the COO's time least of all.
The typical result: you choose what's most visible, not what's most profitable. You automate whatever triggered the last incident, not whatever generates the greatest silent cost. And three months later, the project stalls because the impact wasn't sufficient to justify continuing.
There is a more disciplined approach.
Three variables that define the real value of an automation
Before evaluating any process as an automation candidate, it's worth measuring it against three concrete variables:
1. Execution frequency
How many times does this process occur per week or per month? A process that runs 200 times a month has a very different impact potential from one that runs twice.
2. Cost of error
What happens when this process fails or is executed incorrectly? In some cases, the cost is an hour of rework. In others, it's a regulatory fine, a duplicate invoice, or a client who doesn't receive a timely response. The cost of error isn't always visible in the budget, but it exists.
3. Execution time per cycle
How much time does a person spend each time this process runs? Multiplied by frequency, this yields the total monthly hours consumed.
With these three variables, you can build a simple matrix. No specialized software is required: a spreadsheet listing the ten processes most frequently mentioned by the team is enough to get started.
How to apply the matrix in practice
The exercise has four steps:
Step 1: List the candidate processes
Ask each area owner to identify the three processes that consume the most time or generate the most errors. Don't filter yet. The goal is a list of 15 to 25 candidates.
Step 2: Score each process
Assign a value from 1 to 5 to each variable for each process. High frequency = 5. High cost of error = 5. High execution time = 5. Multiply the three values. The result is a priority index.
Step 3: Filter by technical feasibility
Not every high-index process is immediately automatable. Some depend on systems without an API, on documents in unstructured formats, or on decisions that require human judgment in every instance. Remove those with high technical barriers in the near term.
Step 4: Select the top two or three
From the filtered list, choose the processes with the highest index that are technically feasible. Those are the candidates for a first implementation phase.
A concrete example: a distribution company with 80 employees
A distribution company in Spain was manually managing the reconciliation between purchase orders, delivery notes, and vendor invoices. The process was handled by one person on the finance team, running approximately 300 cycles per month, with an average of 8 minutes per cycle and a cost of error that included duplicate payments and discrepancies detected weeks after the fact.
Applying the matrix: frequency 5, cost of error 4, execution time 3. Index: 60. One of the highest values on their list.
With a reconciliation agent implemented over six weeks, the process ran automatically for 80% of cases. Discrepancy cases were escalated to the team with a pre-prepared summary. The estimated savings: between 35 and 45 monthly hours for the finance team, plus a reduction in payment errors that in prior months had generated credit notes and rework.
This isn't a total overhaul. It's a concrete result on a specific process, chosen with clear criteria.
Why a limited budget is an advantage in disguise
When the budget is ample, it's easy to approve projects without rigor. When it's limited, it forces precise prioritization. That precision, applied from the outset, produces something valuable: an initial internal success case that justifies the next investment.
The organizations that advance fastest in automation are not those with the largest budgets. They're the ones that choose the first process well, implement it with discipline, and use that result to build the case for the next one.
The method described here doesn't require a data team, process mining software, or a six-month consulting engagement. It requires two weeks of structured work with the operations team and the willingness to measure before deciding.
What to do with the processes left out of the first phase
The list doesn't disappear. Processes with a mid-range index or current technical barriers are candidates for later phases. Documenting them from the start has value: once the team has gained experience with the first agents, the next prioritization exercise will be faster and more precise.
The goal is not to automate everything. It's to build an internal capability that allows continuous automation — with clear criteria and measurable results.
Conclusion
Deciding what to automate first is not a technical decision. It's a business decision that requires a clear method and basic data that already exists within the organization.
If your team has the list but not the method to rank it — or if you want to pressure-test your prioritization with someone who has worked through this process with other companies of similar size — you can request a free diagnostic. No introductory call required. No commitment. Just the form at the bottom of this page.
