What Process Should You Automate First?

The short answer

The first process to automate is usually not the task people complain about most. It is the smallest recurring workflow where all of the following are true:

1. The current cost or constraint is measurable.
2. The work repeats often enough for improvement to compound.
3. The normal path and important exceptions can be described.
4. The required inputs and completion evidence are accessible.
5. One person owns the operating result.
6. Success can be measured after the change.

That combination matters more than whether a workflow sounds impressive or whether a tool can connect to it.

The purpose of this article is not to produce a perfect automation roadmap. It is to help one candidate reach a responsible next decision: investigate, stabilize first, keep human, or stop.

Why the loudest process is often the wrong one

Urgency distorts priority.

A slow CRM screen is visible every day. A frustrating approval attracts complaints. A new AI demonstration creates excitement. Those signals may identify real problems, but they do not tell you which problem has the strongest business case.

The more expensive workflow often sits one layer deeper:

• Managers reconstruct completed jobs before payroll can begin.
• Office staff re-key the same information between systems.
• Someone corrects missing photos, hours, or customer details after every handoff.
• One experienced employee carries the exception rules in their head.
• Invoices wait because the evidence of completed work is incomplete.

These workflows may not feel dramatic. Their cost accumulates quietly through repetition, correction, waiting, and dependency.

Automating the visible irritation while leaving the deeper handoff unchanged can produce a technically successful system with little operating value.

Begin with a bounded outcome

“Automate reporting” is not yet a useful scope.

“Produce one complete, approved daily job record within ten minutes of a crew finishing work” is closer. It describes an observable end state, a time boundary, and the evidence that must exist.

Use five questions to set the boundary:

Question	What a useful answer exposes
What starts the workflow?	A real event, record, request, or time condition
What must be true when it finishes?	An observable operating result
Who owns that result?	One accountable process owner
What evidence proves completion?	A record, status, approval, calculation, or handoff
What happens next?	The downstream person or system relying on the output

If the workflow has several unrelated outcomes, owners, or risk models, split it. The first automation candidate should be small enough to understand and important enough to measure.

Measure the current workflow before scoring it

An automation business case begins with the current state.

A simple recurring labor estimate is:

Monthly workflow labor = frequency × average minutes per case ÷ 60 × loaded hourly cost

That is only the starting point. Also investigate:

• time spent correcting incomplete or inaccurate work;
• management time spent chasing updates;
• delays before payroll, invoicing, scheduling, or customer communication can continue;
• avoidable errors and the cost of resolving them;
• key-person dependency;
• capacity that cannot grow without adding administration.

Separate three different types of evidence:

• Verified fact: supported by records, observation, or a reliable system.
• Estimate: a named person’s best current approximation.
• Unknown: material information that still needs evidence.

Do not make an estimate look like a measurement. A rough estimate is useful when it is labeled and tested before an investment decision.

Use representative cases

One clean example rarely represents the process.

Inspect normal cases, difficult cases, corrections, cancellations, and the cases people handle through messages or spreadsheets instead of the official system. The purpose is not to document every rare possibility. It is to understand whether the workflow is stable enough to design and where human judgment must remain.

Score six dimensions

Use this scorecard as a screening tool, not as an automatic approval.

Score each dimension from zero to two:

• 0: weak, unknown, or unsuitable;
• 1: plausible but evidence is incomplete;
• 2: strong and supported by evidence.

Dimension	0	1	2
Economic relevance	Cost or constraint is unclear	Material impact is plausible	Material impact is measured
Repetition	Rare or unpredictable	Recurs, but volume varies	Frequent, repeated, and observable
Process stability	Rules change constantly	Normal path exists with unresolved gaps	Normal path and critical exceptions are understood
Data accessibility	Inputs are unavailable	Some inputs require cleanup or access work	Required inputs and outputs can be accessed reliably
Safety and control	Failure could act without a safe boundary	Risks are known but controls need design	Approvals, limits, escalation, and evidence can be defined
Ownership and measurement	No owner or success measure	Owner or measure is incomplete	Named owner, baseline, target, and review date exist

A high score does not override a critical risk. An unavailable source of truth, prohibited action, unsafe failure mode, or absent process owner can stop a candidate regardless of its economic value.

Interpret the result

Use the total only to guide the next conversation:

• 10–12: strong candidate for a deeper workflow and feasibility assessment.
• 7–9: promising, but close the evidence or control gaps first.
• 4–6: improve or stabilize the human process before designing automation.
• 0–3: stop, redefine the outcome, or choose another workflow.

These ranges are a practical heuristic, not a financial promise. The deeper assessment still needs to verify cost, feasibility, exceptions, security, and adoption.

Test the candidate against four failure questions

Before continuing, ask what could make the score misleading.

1. Are we preserving avoidable work?

If a step cannot change the result, evidence, control, or downstream handoff, question why it exists.

Do not automate duplicate approval, unnecessary copying, or a report nobody uses simply because it appears in the current process.

2. Are the rules actually stable?

A workflow repeated every day may still be unstable if the policy changes by manager, customer, location, or mood.

Stabilize the decision rule or keep the decision human. Automation should not hide an unresolved operating disagreement.

3. Can failure be detected?

“The automation ran” is not completion evidence.

Define what proves the intended result occurred. Name the timeout, validation, retry limit, escalation owner, and record retained when the normal path fails.

4. Will the team use the new path?

An automation that bypasses how work is actually performed creates another workaround.

Observe the users, tools, timing, connectivity, and incentives around the workflow. Adoption is part of the design, not a training task added after the build.

An illustrative field-service example

Consider a company where crew information reaches the office through calls, messages, photos, and handwritten notes.

The initial request might be “automate payroll.” That scope is too broad.

A better candidate could be:

When a job is completed, create one validated work record containing the crew, location, hours, job reference, required photos, and manager approval before the payroll cutoff.

This candidate is useful because:

• the trigger and output are observable;
• the work repeats across jobs;
• missing information creates correction and delay;
• completion evidence can be defined;
• payroll depends on the output;
• one operating owner can review the result.

The automation design may eventually calculate or transfer payroll inputs. But the first decision is whether the job-completion record can become reliable, controlled, and measurable.

That distinction prevents the team from automating a downstream symptom while the upstream evidence remains incomplete.

Decide what should remain human

Choosing a workflow does not mean automating every step.

Classify each action:

• Automate: stable rules, accessible evidence, bounded authority, verifiable result.
• Assist: a system prepares information or a recommendation for human review.
• Keep human: judgment, negotiation, empathy, material approval, or ambiguous evidence remains central.
• Do not perform: the action does not contribute to the result, control, proof, or handoff.

Many valuable systems combine all four classifications. The goal is a reliable operating result, not the largest possible automation percentage.

Leave the screening with a decision record

Do not end with “this looks promising.”

Record:

1. the bounded workflow and desired result;
2. the current baseline and evidence confidence;
3. the score for each dimension;
4. material unknowns and critical risks;
5. the proposed classification of important steps;
6. the owner;
7. the next decision and its date.

The next decision should be one of:

• run a deeper assessment;
• collect named missing evidence;
• stabilize and test the human process;
• keep the workflow human;
• stop investigating.

Clarity at this stage prevents an attractive idea from becoming an open-ended software project.

A checklist for your first candidate

Before proposing a build, confirm:

• [ ] The workflow has one observable trigger and end state.
• [ ] Its cost, delay, error, risk, or capacity effect is material.
• [ ] The baseline separates facts, estimates, and unknowns.
• [ ] The workflow repeats often enough for improvement to compound.
• [ ] The normal path and critical exceptions have been observed.
• [ ] Inputs, outputs, systems, and permissions are known.
• [ ] Human decisions and approval boundaries are explicit.
• [ ] Failure can be detected, stopped, and escalated.
• [ ] One person owns the operating result.
• [ ] Success has a measure and review date.

If several boxes remain empty, that is not a reason to force a build. It is the work required to make the next decision responsible.

WRITTEN FROM OPERATING EXPERIENCE

Denis Rafailov

Denis has spent 14 years building business software and operational automation. AITOC uses this material to help operators make better workflow decisions before anyone recommends a build.