Automate a clear process first

Automation becomes useful when the process, inputs, expected result and exception route are clear enough to test and maintain.

A team spends hours moving information between systems. Automation looks like the obvious answer. It may be, but first ask whether the information is reliable, the rules are clear and somebody knows what to do when an exception occurs. A machine can repeat a process quickly without making that process sensible.

The right starting point is a bounded task with a visible result. Repetition, clear inputs and a reversible outcome make a useful first candidate. High consequence decisions, ambiguous instructions and confidential data require more careful controls.

Map the normal path and the exceptions

Write the trigger, required information, steps, result and person responsible. Then list the ordinary exceptions. What happens when a field is missing, the customer changes a request, a system is unavailable or two records disagree?

The exceptions matter because real work rarely consists only of the ideal path. A demonstration can look impressive with clean sample data while failing on the first untidy record. The business needs a useful recovery route, not just a successful animation in a sales presentation.

Ask the person doing the work to show recent examples. Their informal judgement may be holding the process together. If that judgement cannot yet be described, the first improvement may be clarifying the rules or using an assistant that prepares work for review.

Calculate capacity released honestly

Suppose a fictional task takes 15 minutes and occurs 80 times each month. That is 20 hours of current work. If review and exception handling after automation require five hours, the estimate is 15 hours released before considering maintenance and implementation effort.

Do not automatically translate those hours into a salary saving. Staff may use the capacity for other valuable work while payroll remains unchanged. A real cost reduction requires a real change in expenditure. Capacity, service speed and fewer errors can still be worthwhile benefits when described accurately.

Include the time spent maintaining the automation, updating rules and investigating failures. A process that saves ten minutes but creates an hour of checking is not an improvement merely because software performed part of it.

Keep judgement at the right boundary

Rules and language models do different jobs. A fixed calculation should use deterministic logic that can be tested. A language model may help summarise text or draft a response, but its output requires an appropriate check. Do not give it authority simply because it sounds confident.

The NIST AI Risk Management Framework provides an official reference for considering AI risks. The practical point for an owner is to identify consequences, responsibilities and controls before relying on a system. This article's task selection method is an original teaching approach, not a certification under that framework.

Automate the repeatable work. Keep the exception and its owner visible.

Design the failure before celebrating the success

Specify what happens when the provider is unavailable, a request is repeated or an output fails validation. Preserve the original information. Avoid duplicate messages, payments or records. Give the responsible person enough context to recover without reconstructing the entire task.

Prefer supported interfaces and controlled access. Keep credentials out of public code and limit permissions to what the task needs. An automation that requires unrestricted access to everything should face a more demanding review than one that reads a narrow set of approved records.

Set a spending limit where a paid service is involved. A public or frequently triggered AI feature can create cost through ordinary repetition or abuse. Rate limits, bounded requests and a clear stop condition are part of the business design.

Run a useful pilot

Choose a short, representative sample that includes normal work and known exceptions. Define success before the test: accuracy, review time, recovery behaviour and the result that users need. Keep a manual route available while the process is being proved.

Review the errors, not only the successful cases. Ask whether the task is better overall and whether somebody can maintain it. If the automation depends on one person remembering undocumented fixes, the business has moved the dependency rather than removed it.

What should the baseline include?

Measure a representative sample of the current work before introducing the system. Record the time spent completing the task, checking it and correcting errors. Include examples that are awkward as well as those that follow the ideal path. If the baseline covers only easy work, the comparison can exaggerate the benefit. Ask the person performing the task to identify interruptions and informal checks that a stopwatch alone may not explain.

Define quality in terms of the result the business needs. A summary may need to preserve decisions accurately, while a record transfer may need every approved field to arrive once and only once. Speed matters only in relation to an acceptable output. A system that produces an incorrect result quickly can increase the effort required downstream. Set the acceptance condition before the pilot so that the team does not lower it merely because the demonstration looks impressive.

How do you prevent duplicate or unintended actions?

Separate preparing an action from authorising it where the consequence warrants that boundary. A system can draft a message or assemble a record while a person checks the important details before it is sent or committed. Use a stable reference for work that might be retried, and check whether the intended action already happened before repeating it. A timeout can mean that confirmation was lost, not that the first attempt failed.

Give exceptions an owner and enough context for recovery. Preserve the original input, the attempted step and the result received. Avoid sending confidential content into an unrestricted error log. The responsible person needs to understand what happened without being given more sensitive information than the task requires. Recovery should be designed as part of the process, because a system that cannot be repaired safely is difficult to rely on even when most runs succeed.

What happens after the pilot?

Assign maintenance responsibility before treating the automation as routine. Someone must notice when a source field changes, an integration stops working or a provider behaves differently. Keep the operating instructions accessible and record the limits of the system. A workflow maintained through undocumented fixes in one person's memory has created a new dependency, even if it removed an older manual task.

Review total value after the system has been used on ordinary work. Include subscription or usage charges, review effort, corrections and the time needed to maintain it. Record what the released capacity was used for. Improved service or additional throughput can be worthwhile, but should be described as those benefits rather than an invented payroll saving. If the pilot does not improve the work, stop or revise it. The practical next decision is whether the evidence supports continued use, not whether the technology was fashionable enough to justify the experiment.

Select one repetitive and reversible task. Write its exception route and accountable owner before choosing the software. That small discipline makes the next demonstration much easier to judge.