Automation that pays off: calculate capacity, cost and exceptions before you build

The appeal of automation is obvious: less repetitive work, fewer handoffs and faster service. But a task that takes a long time is not automatically a good automation candidate. A process may be rare, poorly defined or dominated by exceptions. Automating it can simply move the problem into software.

A useful automation business case combines three things: the economics of the work, the reliability of the process and a credible plan for using the capacity released.

1. Simplify the process before connecting systems

Write down the trigger, required inputs, decision rules, expected output and accountable owner. Remove steps that no longer serve a purpose. If staff disagree about the correct process, resolve that disagreement before building an integration.

Consider creating a customer record after an enquiry. Before automating, decide what counts as a duplicate, which fields are required and what happens when the information is incomplete. These are operating decisions, not implementation details to leave to a developer.

2. Measure actual effort, including the awkward cases

Measure handling time on a representative sample. Include checking, correction, searching for information and escalation. Record how often exceptions occur and how much time they consume. Separate time spent working from time a case waits in a queue; reducing one does not necessarily reduce the other.

Then estimate the average human effort after automation, including review and exception handling. If a proposed solution saves data-entry time but doubles checking time, the headline saving is misleading.

3. Use a transparent calculation

The following is an illustrative calculation, not a client result or a forecast. Suppose a business processes 400 requests per month, spending six minutes on each. That is 40 hours. If the new process needs two minutes of human effort per request on average, including review and exceptions, it requires about 13.3 hours. The capacity released is about 26.7 hours per month.

At an assumed fully loaded labour cost of ₪100 per hour, the capacity has a notional value of about ₪2,670. If recurring software and maintenance cost ₪600 monthly, the estimated net capacity value is about ₪2,070. With an assumed setup cost of ₪8,000, simple payback on that basis is roughly 3.9 months.

This is not automatically a cash saving. Cash payback requires an actual reduction in paid hours or other cash benefits. If staffing stays unchanged, the benefit is capacity. Define how that time will be used: faster customer response, more proposals or less overtime. Otherwise the spreadsheet may show value that the business never captures.

Test a conservative scenario too: lower volume, higher review time or increased maintenance. Include training, monitoring and any migration work in the investment rather than hiding them outside the calculation.

4. Design what happens when something goes wrong

Reliable automation needs a visible exception path:

• Missing information: route the case to a named person, rather than silently skipping it.
• Duplicate events: prevent the same action from creating duplicate records or charges.
• Temporary connection failure: retry safely, with limits and a clear escalation.
• Uncertain decisions: require human approval where the cost of a mistake is material.
• Traceability: record what happened, when it happened and which case was affected.

Someone must own the exception queue. An alert that nobody reviews is not a control. Access should be limited to the information and actions the integration actually needs, and sensitive data should not be copied into logs unnecessarily.

5. Pilot before expanding

Start with a bounded set of cases and keep a manual fallback. Compare total human effort, completion time, error rate and the number of unresolved exceptions with the baseline. Review cases that failed, not only the average performance of those that succeeded.

Agree on rollout conditions before the pilot begins. For instance, the business can set its own threshold for acceptable error rates and response time, while requiring that every exception has an owner. These thresholds depend on the process; there is no universal safe target.

The best first automation is often a repeatable, well-understood task with measurable volume and manageable risk. Its value comes from a better operating process, not from how many systems it connects.

Further reading

McKinsey: What is digital transformation? provides context on business value, operating models and adoption. The calculations and implementation checklist above are our own practical synthesis; the source does not validate the illustrative return.