How to know if a process needs automation

Automating a process can reduce time, errors and operational burden. It can also speed up a poorly designed process, propagate bad data, or shift the bottleneck elsewhere.

The useful question is not “what can we automate with this tool?”, but “what friction has enough impact, repetition, stability, and control to justify intervention?”

1. Draw the process that actually occurs

Start with a recent case and reconstruct its entire journey. Don't just use the written procedure: follow what people actually did.

Documents trigger, inputs, people responsible, systems, decisions, waits, exceptions and results. Pay special attention to transfers between people and tools. Many invisible costs appear there: copying data, asking for statuses, reconstructing context, checking versions or chasing approvals.

2. Separate activity, waiting and rework

A process can consume a few minutes of human work and take days to complete. That is why it is convenient to measure three components separately:

• Activity time: direct work.
• Waiting time: time without progress.
• Rework: work repeated due to error, lack of data or change of criteria.

Automating activity does not always solve waiting. If the real bottleneck is an approval that takes two days, reducing five minutes of manual copying makes little difference to the outcome of the process.

3. Eight signs of a good automation opportunity

Sufficient volume

Repetition turns seconds into meaningful capacity. Calculate cases per period and time per case. There is no universal minimum volume: it depends on the cost of implementation, the risk and the value of each transaction.

Clear enough rules

Not everything should be deterministic, but it should be possible to distinguish between normal cases, exceptions, and decisions that require human judgment.

Accessible tickets

Automation requires consistently available information. The data can come from forms, databases, emails or documents, but there must be a mechanism to check minimums and manage absences or contradictions.

Verifiable output

It must be possible to define what correct result the step produces. If no one can say what “done well” means, it will be difficult to automate and even more difficult to test quality.

Observable error cost

Duplicates, omissions, delays, lost tracking, poorly copied data or incorrect documents make the impact of friction visible.

Next step prepared

If an automation produces 500 cases a day for a person who can only review 50, you haven't eliminated the bottleneck: you've moved it.

Process owner

Someone must have authority to define rules, accept changes, resolve exceptions, and evaluate results.

Reasonable stability

A process that changes every week usually needs design and standardization first. Automating unstable rules turns every change into technical maintenance.

Automating a task is not equivalent to improving a process.

4. Design exceptions before the happy case

Real processes include situations outside the rule. The quality of an automation depends a lot on how you manage it.

Inventory known exceptions: incomplete information, different formats, down systems, conflicting data, out-of-catalog requests, amounts above a certain threshold, or cases that require a human decision.

For each exception define:

1. What detects that something doesn't fit.
2. What part of the flow stops.
3. What context is recorded.
4. Who is escalated to?
5. What can the person correct?
6. How the case returns to normal flow.

Good automation doesn't try to hide uncertainty. It makes it visible and directs it to the right person.

5. Evaluate the operational quality of the data

Before automating, review where the information comes from and what each field means. Many failures attributed to automation are actually data problems.

If three systems contain different state of the same customer, automation alone cannot resolve an organizational contradiction. First you have to decide which system is in charge.

6. Decide what type of intervention the process needs

Not every improvement needs full automation. There are at least four types of intervention:

Estandarizar

Define rules, responsible parties, minimum fields and states. Many times it is the first step.

Asistir

Technology prepares information, suggests or classifies, but a person decides.

Automatizar

The system executes known rules from start to finish within limits.

Orquestar

Coordinates various systems, decisions and responsible parties, including exceptions and supervision.

Choosing the right intervention avoids building more technology than necessary.

7. Use a score to compare opportunities

Rate each dimension from 1 to 5 and document why. Don't add without thinking: some dimensions act as a veto.

• Volume and frequency.
• Current cost of time.
• Cost of errors.
• Clarity of rules.
• Data quality.
• Ease of integration.
• Process stability.
• Risk of incorrect execution.
• Ease of measuring the result.
• Team's ability to operate exceptions.

An opportunity with high impact, clear rules, reliable data and controlled risk is usually a better first case than a flashy but ambiguous and critical task.

8. Calculate the cost of current friction

Before calculating savings, quantify the problem. A simple model may include:

Operating cost = volume × average time × hourly cost.

Then add rework, errors, penalties, waiting costs or future hires when observable.

Hypothetical example: 2,000 cases per month × 3 minutes of manual copying = 100 hours per month. If the automated flow reduces that task to 30 seconds of average monitoring, you must still include exceptions, infrastructure, and maintenance before calculating return.

9. When it is not convenient to automate yet

• The process is constantly changing.
• There is no source of truth.
• The volume is low and the impact small.
• The real problem is poorly defined responsibility.
• The cost of an error is high and there is no adequate control.
• The organization cannot maintain the system.
• The case has been chosen because a technology is in fashion.
• There is no metric to know if it worked.

10. Design a pilot that reduces uncertainty

A pilot should not try to prove that technology “can do it.” It should answer business and operational questions.

It also defines guardrails. If the time goes down but errors increase, the pilot has not worked. If you eliminate manual work but create an equivalent review, the real return is limited.

11. Test adverse cases and not just clean examples

Includes incomplete records, duplicates, unexpected formats, extreme values, integration crashes, and simultaneous state changes. The system must fail in a controlled manner.

The goal is not to prevent any errors; is to prevent a silent mistake from becoming a wrong decision at scale.

12. Design who will maintain the automation

An automation is an operational product. Processes change, APIs change, credentials expire and new exceptions appear.

Define from the beginning:

• Business owner.
• Technical manager.
• Incident channel.
• Alerts and observability.
• Rule change process.
• Testing before deploying changes.
• Reversal plan or manual operation.

13. How to know if automation should be expanded

After the pilot, compare against the baseline. It expands when the system improves the result consistently and the operating cost is understood.

Don't scale just because it “works.” Ask if it continues to operate with more volume, more users, more exceptions, and more dependency on other systems.

Conclusion

The best automation is not the one that eliminates the most clicks. It is the one that improves an important operating variable with a reasonable level of risk and maintenance.

Before you build, understand the journey, quantify friction, resolve data ambiguities and responsibilities, design exceptions, and define how you will measure the outcome. Only then does technology stop being a gamble and become an evaluable business intervention.

If you want to see the approach we use to analyze processes before implementing, you can consult how we work.