Automation ROI: is this task actually worth automating?

Measure the task before choosing the tool

Describe the start and finish in one sentence. For example: when an approved order arrives, copy the agreed fields into the fulfilment system and confirm that the record exists. “Automate operations” is too broad to measure.

Watch several real attempts, including awkward ones. Record active working time separately from time spent waiting for approval. A task sitting in an inbox for a day does not mean someone spent a day working on it.

• Volume: how many times the task occurs in a normal month.
• Handling time: minutes of human work per occurrence.
• Exceptions: missing fields, duplicates, unusual requests and failed transfers.
• Baseline quality: corrections or missed actions you can actually count.

Use a longer observation period if demand is seasonal. Label estimates as estimates. A quiet Tuesday is not a reliable basis for forecasting a whole year.

Count the work that remains after automation

An automation might move the data but leave someone checking it. It may also create an exception queue that did not exist before. Include both when estimating time saved.

For different staff roles, value the hours separately using an agreed internal cost rate. Do not assume the same rate applies to administration, specialist review and technical maintenance.

Microsoft’s guidance on measuring business value recommends comparing costs with benefits and choosing appropriate measures for the solution. A tool-generated ROI figure is still dependent on the assumptions entered into it. [1]

Separate useful capacity from money saved

If a salaried employee saves five hours, the payroll bill usually stays the same. The benefit is capacity: time that can be used for other work. Count it as cash savings only when expenditure actually falls, such as reduced paid overtime or an avoidable contractor charge.

Write down what the freed time will be used for. Clearing a support backlog is a more credible plan than assuming every spare hour turns into extra sales.

You can still value capacity in a business case. Just keep it separate from the cash forecast. Do not count the same hours once as labour savings and again as additional revenue without explaining the relationship.

Use a worked example, then change the assumptions

The following numbers are hypothetical, not a Purple Scale customer result or a market benchmark. All amounts are in USD and use a single illustrative labour cost of $30 per hour.

This four-month figure is not cash payback unless the capacity value becomes an actual financial benefit. It assumes steady volume, immediate full adoption and no additional costs beyond those listed. It excludes financing and tax effects.

Now assume the task occurs only 150 times a month. Baseline work becomes ten hours, review takes 2.5 hours, and the same three hours of maintenance and exceptions remain. Only 4.5 hours are freed. At $30 per hour, less $60 in software costs, net capacity value is $75 a month. The same setup cost now takes 16 months to recover on that basis.

Run a cautious case before committing. Lower volume, slower adoption or more exceptions can change the decision. If the monthly net benefit is zero or negative, this model gives no positive payback.

Include setup costs that are easy to miss

• Discovery and process design, including staff time.
• Data cleanup, access permissions and integration work.
• Testing, training and documentation.
• Software subscriptions, usage charges and additional seats.
• Monitoring, repairs and changes when connected systems change.
• A fallback process for outages or incorrect results.

Use incremental costs: what this project adds to what you already pay. If it triggers a software upgrade, include that difference. If several workflows share a subscription, document how you allocate it rather than counting the full amount against every task.

Keep quality improvements visible but separate until measured. “Fewer mistakes” is a useful hypothesis. It is not a saving you can price confidently without knowing the frequency and cost of those mistakes.

Decide where AI helps and where a person takes over

A fixed rule may be enough to move approved fields between systems. AI may help when the input is unstructured, such as extracting a proposed request category from an email. That introduces a different testing and review requirement.

NIST’s AI Risk Management Framework calls for defined oversight responsibilities, monitoring and contingency processes. Use those principles to decide who checks outputs and what happens when the system fails. They do not establish that a particular workflow is safe. [2]

For example, an incomplete or conflicting order should go to a named reviewer instead of being silently completed. Payment changes, sensitive information and consequential customer decisions need controls appropriate to their risk. Do not rely solely on an AI-generated confidence score.

Make the pilot earn a wider rollout

Choose a limited scope and define the decision before starting. Record the same measures before and during the pilot: completed tasks, actual review time, exceptions, corrections and running costs. Include failed runs, not just successful ones.

If the pilot saves little time, simplify the process before adding more technology. Removing an unnecessary approval or standardising an input form may be the better intervention.

Use Purple Scale’s task assessment as a starting estimate, then replace assumptions with observed figures. If the result looks promising, the next step is a scoped workflow review, not a commitment to automate everything.