Automate frequent, predictable business processes first, where the inputs are reliable, mistakes are easy to catch and the time saved exceeds the effort of running the automation. Transferring approved data between systems, assembling routine reports and sending internal reminders are sensible candidates to assess. Leave payments, sensitive decisions and processes with unclear rules out of the first pilot unless there is a compelling reason and suitable oversight.

The first project should prove a useful improvement, not demonstrate the most impressive technology. Compare the work before choosing software: how much attention it consumes, what causes delays, what could go wrong and how difficult it will be to maintain. Only then decide whether conventional automation, AI or a simpler process change is appropriate.

Shortlist tasks, not whole departments

"Automate finance" is too broad to evaluate. "Create a draft invoice from an approved order, ready for someone to check" gives you a trigger, an input, an output and a boundary. Describe each candidate at that level. Include where the work starts and what counts as finished, rather than stopping when information leaves the first system.

Ask the people doing the work to identify repeated copying, chasing, checking and reformatting. Choose five candidates initially. Include quiet frustrations as well as visible bottlenecks: a daily reconciliation may deserve attention before an occasional report that attracts more complaints.

For each candidate, record its owner, monthly volume, hands-on time, waiting time, systems involved and common exceptions. Observe representative cases rather than relying entirely on estimates. Include an awkward case, such as a missing reference or amended order, so the assessment does not assume every input arrives complete.

Check whether the task should exist

Before scoring a candidate, ask whether you can remove or simplify it. A report nobody uses should be retired, not generated faster. Repeatedly correcting incomplete enquiries might be better addressed by changing the form. Duplicate entry may disappear if one system becomes the agreed source of truth.

Check existing software settings too. Look for an appropriate scheduled export, validation rule or notification before commissioning a separate integration. Confirm what your actual version and subscription support. If staff disagree about what should happen, settle the process first: software needs an agreed rule, or an explicit route to a person who can decide.

Compare value, effort, cost and risk separately

Use a shared comparison sheet rather than asking everyone to nominate their favourite project. Give each candidate a low, medium or high assessment against the following four dimensions, with a short explanation. Treat this as a discussion aid, not a mathematical prediction.

  • Value: estimate recoverable staff time, avoidable rework and the benefit of shorter delays. Identify who gains the capacity and what they would use it for.
  • Implementation effort: consider data quality, system access, integration options, testing and staff training. A short task can still require difficult technical work.
  • Whole-life cost: include discovery, build, subscriptions, usage charges, support and future changes. Include internal time spent reviewing outputs and handling failures.
  • Risk: assess the consequence of an incorrect, missing, duplicated or late action. Consider who would notice, how quickly and whether the action can be reversed.

Prioritise meaningful value with modest effort and contained risk. Use risk as a gate, not merely a score that a large time saving can outweigh. An unattended change to supplier bank details should not beat an internal reporting task simply because it promises more hours back.

Record uncertainty separately. If nobody knows whether a legacy system permits reliable data access, commission a small technical investigation before accepting a delivery estimate. A promising candidate with an unresolved dependency belongs on the investigation list, not automatically at the top of the build queue.

Calculate the saving after human review

Start with monthly volume multiplied by average hands-on time. Then subtract the work that remains: approvals, exception handling, checking results and maintaining the automation. Keep waiting time separate. Removing a two-day delay may improve service, but it does not necessarily recover two days of staff time.

For a hypothetical example, suppose staff transfer 400 approved records each month, taking three minutes per record. That is 20 hours of manual effort. If the proposed automation still needs four hours of review and two hours of maintenance each month, the estimated capacity released is 14 hours, not 20. These are illustrative assumptions, not expected results.

Compare that with a hypothetical report taking six hours monthly, reduced to one hour of checking. It releases only five hours, but could be the better first project if it needs much less implementation work and cannot alter customer records. The larger saving is not automatically the better starting point.

Released capacity is not automatically a cash saving either. Explain whether it will absorb growth, clear a backlog or reduce paid overtime. For a financial comparison, divide the one-off implementation cost by the estimated monthly net benefit, after running costs. Test the calculation with lower volumes and more review time before treating the payback estimate as a funding decision.

Choose the technology after the process

Prefer conventional automation when inputs are structured and the rules are explicit. Moving an approved order into a fulfilment queue or checking whether a required field is empty does not inherently need AI. Rules-based software is easier to inspect when you can state exactly what should happen for each condition.

Consider AI when useful information arrives in variable language or document layouts, such as categorising incoming enquiries or extracting details for review. Evaluate that interpretation step separately from the action it triggers. A useful draft classification does not establish that an unattended customer response is safe.

A mixed approach may fit: AI proposes a category, fixed rules check required information, and a person approves uncertain cases. Include that review workload in your comparison. If every output needs substantial correction, the apparent saving may disappear.

FullyCoded's guide to automating business workflows safely explains where human approval belongs in an AI workflow. Use it once you have shortlisted a process that genuinely needs interpretation, rather than making AI the starting requirement.

Turn the strongest candidate into a bounded pilot

Select one workflow, one responsible owner and a limited set of cases. Define success before building: lower handling time with no unacceptable increase in errors, for example. Measure the current process over a representative period, including busy days and exceptions, so there is a fair baseline.

Ask whoever implements it to demonstrate more than the successful path. Test missing data, duplicate triggers, unavailable destination systems and corrected records. Require a way to see what completed, what failed and what still needs attention. Agree who receives failure notifications and who covers their absence.

Where practical, start by generating drafts or comparing proposed outputs with manual results before allowing live changes. Document how to pause the automation and resume manual work without losing or duplicating cases. Set a review date after enough representative cases have passed through, rather than declaring success because the first demonstration worked.

At that review, compare actual handling time, exception volume, errors and running costs with the original assumptions. Expand only if the result holds up. Your next step is to put five specific tasks on a comparison sheet, remove unnecessary work and choose the smallest valuable process you can measure, control and reverse.