Business Process Automation: What to Automate First

Defining the process’s start, finish and expected result makes its workload measurable. “Improve operations” gives the team no clear unit to count. “Take an approved order from receipt to an accurate record in the order system” identifies a completed case whose handling time and accuracy can be checked.

Process volume, handling time and exceptions determine how much work automation could remove. A frequent task may take little effort, while an infrequent exception may consume hours. Measuring routine and exceptional cases separately shows where the workload concentrates.

Staff effort and approval delays need separate measures because automation affects them differently. A request might take ten minutes of staff effort but sit in an approval queue for two days. Shortening that queue can improve service without reducing the time someone spends completing the request.

A shortlist needs the same evidence for each process so that frequent, visible tasks do not automatically take priority. Record the monthly workload, expected improvement, implementation dependencies and ongoing responsibilities for each candidate. Note where a figure is measured and where it is still an assumption.

Unresolved access or decision rules can make a promising process unsuitable for the first implementation. A workflow that depends on unavailable system permissions needs that dependency resolved before its benefits can be relied on. A smaller process with accessible inputs and an owner able to accept the result may provide a more practical starting point.

The first process should have a useful outcome that can be verified within an agreed scope. Define what would count as success and what would stop the work from proceeding. If two candidates appear comparable, investigate the assumption most likely to change their order, such as exception effort or the cost of connecting a system.

Simplifying approvals and removing duplicate records can reduce work before automation begins. The process owner needs to establish which steps are necessary and agree any changes with the people responsible. If the team does not agree on what should happen, automation would encode a disputed process.

Missing or inconsistent data creates exception-handling work that belongs in the implementation estimate. An order without a product code may still need someone to identify the item, while conflicting customer records may require reconciliation. The scope should account for correcting those inputs or handling them when they occur, along with any system-access dependencies.

A sensible outcome of the review may be to simplify the process, improve the data or use an existing feature before commissioning anything new. The comparison should include those options alongside continuing with the current process.

Rules-based automation performs tasks whose decisions and calculations can be specified in advance. Software can check required fields, apply an agreed calculation or route a record according to a defined rule. Each step can be tested against its expected result.

AI can help interpret varied language, provided its outputs can be checked and errors resolved. Extracting order details from differently worded requests is one possible use. The estimate needs to include the time someone spends reviewing uncertain results and correcting mistakes.

Custom software can combine fixed rules and AI to meet requirements that existing tools do not cover. For example, a model could interpret a request before conventional software applies an agreed calculation. AI-assisted development is a separate matter: using AI to build the software does not establish how the finished workflow operates.

An existing workflow needs to accommodate the process’s routine steps, exceptions and system requirements. A straightforward demonstration leaves questions about access permissions, unusual cases and recovery from failures. Those checks help establish the implementation work and ongoing responsibilities.

Custom technology may be appropriate where the agreed requirements are specific to the business or where existing tools leave a material gap. An engagement can combine existing workflows with custom components.

Adaca’s discovery process determines which requirements fit existing workflows and which need custom technology. Adaca Autopilot provides pre-developed workflows, with ongoing operation and support through a product subscription. Adaca AI Pods delivers custom-built technology, with operation and support under a service-level agreement, or SLA. Both arrangements can apply to their respective parts of an engagement.

Workflow availability must be checked against the requirement. The illustrative order process in this guide does not describe an included Autopilot workflow, and our internal payroll example is not a product catalogue entry.

An automation business case compares current effort with implementation costs and the work that remains afterwards. Using equivalent volumes and quality requirements keeps the comparison meaningful. A proposal based only on successful routine cases would leave out effort that the team may still need to provide.

Implementation costs can include discovery, configuration or development, integration, data preparation, testing and training. An internal team’s time is also a resource cost, even when it does not create a new invoice. Ongoing costs can include licences, usage charges, operation, support and maintenance.

Each claimed benefit needs a measure, an accountable owner and an explanation of how it will be achieved. Faster completion could be tracked through elapsed time, while lower spending needs an identifiable reduction in a budget. Released capacity and fewer errors require their own measures; counting the same improvement under several headings would overstate the result.

The following order-processing example is entirely hypothetical. Every figure is an assumption chosen to demonstrate the method. None represents an Adaca price, benchmark or customer outcome.

Suppose a team completes 1,000 order checks a month. Its current average is six minutes per case, including checking and corrections. That is 100 hours of monthly staff effort.

For the proposed process, assume 800 routine cases need one minute of human review each. The remaining 200 exceptions need eight minutes each, including their review and resolution. Add ten hours a month for process oversight and maintenance coordination, separate from those case-level checks.

The frequency and handling time of exceptions can materially change the expected capacity gain. A demonstration built around clean inputs leaves the effort of missing information or unusual cases unmeasured. Testing representative historical work helps replace those assumptions with observed handling times.

Released capacity becomes a cash saving only when it removes spending that would otherwise occur. If the same staff remain on the same salaries, the payroll bill does not fall merely because a task takes less time.

Released hours can support growth or reduce backlogs even when they do not lower current spending. Those benefits need evidence of the work waiting to be done and the team’s ability to use the available time. Avoided future hiring also depends on a credible workload forecast and whether the released hours match the role, skills and timing of the planned hire.

For the hypothetical order process, suppose 20 of the 50 released hours eliminate separately budgeted overtime at A$60 per hour. Assume the other 30 hours move to existing work and create no immediate cash saving.

Now assume A$12,000 of initial implementation cost and A$700 a month of additional operating costs. These are fictional inputs, not indicative Adaca fees. For this simplified calculation, assume the initial cost covers the full implementation and the operating allowance covers the additional recurring cash costs.

Simple payback is the initial implementation cost divided by the positive monthly cash benefit. Here, A$12,000 divided by A$500 gives 24 months of operation.

The payback period assumes an immediate, constant monthly benefit. During the first 12 operating months, A$6,000 of net cash benefit would recover half of the initial cost. Implementation time or a gradual rollout would push the calendar payback later.

If only ten overtime hours can be avoided, the cash benefit falls to A$600 against A$700 of operating costs. The result is negative A$100 a month, so there is no cash payback under that scenario. The business would need to justify the investment through other evidenced benefits or change the scope.

This simple comparison excludes tax, financing and the time value of money. A final investment case should include those effects where material and avoid treating salary-valued capacity as cash available to repay the project.

Our published September 2026 account of internal payroll automation describes a process built around the requirements of our Philippines payroll. Its calculations use fixed rules. An AI language model does not perform them.

The account records a change from three people involved in calculating payroll to one person overseeing the process. Human work remained, including checks on calculations, leave entries and approvals.

That comparison describes participation in a process. It does not establish two full-time roles saved, employees leaving the business or a financial return. The published account does not supply the hours and costs needed for those conclusions.

The payroll account identifies checks that continued after automation. A comparable review of another process needs to measure its own remaining work. The order example above uses separate, invented inputs and does not reconstruct the payroll project.

Verification needs agreed measures and test cases covering routine work, exceptions and failures. Before implementation, the process owner should define acceptable results and name the person responsible for sign-off. That gives the team a basis for deciding whether the solution is ready to launch.

For an order process, useful measures could include accurate records completed, human minutes per case, unresolved exceptions and elapsed time from receipt to completion. The team should also know how to recover from a failed update or a duplicate request.

Post-launch measurement should compare effort, quality and costs under comparable workloads. Include support time and rework, then check whether the expected capacity or spending change occurred. A faster routine path can still disappoint if exceptions take more time than anticipated.

Discovery starts with evidence of how the process works, what it produces and how much effort it requires. Completed cases help reveal dependencies and difficult decisions that a written procedure may omit. Together, these records give the team a basis for investigating scope and cost.

Where priorities or the business case need further investigation, a scoped assessment can develop the analysis. It is optional and does not commit the business to implementation.

How We Work explains how discovery moves into agreed requirements, verification and ongoing support.