Building a realistic business case for automation

Measure the task you actually intend to change

Define a clear start and finish. Count cases over a representative period and measure active handling time. Waiting for a colleague is different from spending five minutes entering data. Both may matter, but they cannot be added together as if they were the same labour input.

Include quieter days, peaks and exceptions. Record whether a case involves normal processing, correction or clarification. Identify work outside the chosen boundary. Otherwise you may measure a broad current process and compare it with only the easiest future step.

A fictional calculation with three scenarios

Assume 1,200 cases per month currently need an average of five minutes of active work each, including existing corrections: 100 hours per month. In this example, future routine cases need one minute of human checking, while exceptions need six minutes of total human handling. Those six minutes include the check; they are not six additional minutes.

The percentages below describe assumed shares of cases using the routine path, not model accuracy. We also assume eight fixed maintenance hours per month. Licensing, implementation and initial setup effort have not been included in this comparison of hours.

These figures do not establish a return on investment. Longer exceptions, more maintenance or lower volume change the result. With no routine cases, this example would require 120 processing hours plus 8 maintenance hours: 28 more hours than today. Replace the assumptions with your own observations before drawing conclusions.

Available hours are not automatically cash savings

Scattered minutes do not necessarily become a usable working day. Discuss what other work could be done and whether scheduling or responsibilities would need to change. Serving customers sooner or reducing a backlog can be valuable without immediately reducing payroll.

Multiplying hours by an internal hourly rate places a value on capacity; it does not prove lower expenditure. Claim a cash saving only where an actual cost changes, such as a demonstrated reduction in external support or overtime. Do not count the same hours as both a cost saving and extra capacity.

Include costs across the operating life

• One-off work: process analysis, configuration, integrations, testing and staff preparation.
• Recurring charges: licensing, usage, hosting where required and support.
• Internal effort: checks, exceptions, maintenance, change testing and access management.
• Transition: temporary parallel running and resolving errors or backlogs.
• Replacement or exit: moving data, documenting the process and returning to another way of working.

Ask suppliers to explain the assumptions in their quotations and what is excluded. Avoid a precise payback period while material costs remain unknown. Identify the missing information most likely to change the decision first.

Define what the trial needs to show

Agree which observations would support continuing, changing direction or stopping. Use the same process boundaries during the trial as in the baseline. Keep handling time, corrections and exceptions visible separately, and check the quality of the outcome as well.

Give a process owner responsibility for reviewing the figures after introduction. A low-volume month or a period of extra support can be misleading. Update assumptions when evidence changes, but retain the original basis so people can understand why the decision has shifted.

Three useful inputs for an initial conversation

You do not need a finished financial model before discussing the process. An approximate volume, a few examples of manual work and an understanding of the main exceptions provide a useful starting point. The aim is to identify assumptions worth testing, not defend an attractive number.

Which processes are worth investigating?