Workflow Automation: What to Automate First

Automation projects tend to start with whichever process is most annoying to the person who raised it. That is not a bad instinct, but it is not a strategy, and it is why so many automation efforts produce a few scripts nobody maintains.

Picking the first process well matters more than picking the right tool. The first one sets whether anyone trusts the next one.

Score candidates on four things

Frequency

How often does it run? A task performed fifty times a week is worth more than one performed monthly, even if the monthly one takes longer. Small savings compound; large infrequent ones do not.

Determinism

Can the rules be written down completely? "Route the invoice to the department in field four" is deterministic. "Route it to whoever seems most appropriate" is judgement wearing a process costume. Judgement can be supported by automation but should not be replaced by it.

Error cost

What happens when the step is done wrong? Re-keying a customer address wrong means a delivery goes astray. Re-keying a payroll figure wrong means a compliance problem. High error cost raises the value of removing the human step, but it also raises the bar for testing.

Handoffs

How many times does the work change hands or systems? Every handoff is a queue, and queues are usually where the elapsed time hides. A task that takes four minutes of work but three days of calendar time is a handoff problem, and handoffs are the highest-value thing to remove.

The best first candidate

High frequency, fully deterministic, moderate error cost, at least one handoff. Concretely, that usually looks like data being copied from one system into another by a person: entering an order into a second system, re-typing attendance into payroll, transferring form submissions into a tracker.

These are ideal firsts for three reasons. The rules are unambiguous. The benefit is measurable in the first month. And they usually reveal that the underlying problem is two systems not talking, which is a more valuable finding than the time saved.

Four things not to automate as they stand

1. A process nobody can explain

If two people describe the process differently, you do not have a process, you have a habit. Automating it locks in whichever version the person in the room happened to describe.

2. Approval chains that exist for historical reasons

Automating a four-step approval makes a four-step approval faster. Asking why it has four steps often removes three of them. Look for controls that were added after a specific incident and never revisited; a spending threshold frequently replaces the whole chain.

3. Anything about to change

If the process depends on a system being replaced next quarter, or a regulation under revision, wait. Automation built on a moving foundation gets rebuilt.

4. Judgement work

Deciding which customer needs attention, whether an exception is justified, how to handle an unhappy client. Automation can put the right information in front of the person faster. It should not make the call.

Measure before, or you cannot claim after

Before changing anything, record how long the process takes, how often it runs, how often it goes wrong, and how much calendar time elapses start to finish. It takes an afternoon and it is the difference between "this feels better" and a number you can put in front of whoever approved the budget.

Elapsed time is the metric most often skipped and most often the real story. Cutting a task from six minutes to one is fine. Cutting the end-to-end cycle from four days to four hours is what people notice.

Scoring three candidates, worked through

Say a team has three processes on the table. Scoring them against the four criteria makes the choice obvious in a way that arguing about them does not.

A: monthly management report. Runs twelve times a year. Fully deterministic, since it is a fixed set of queries. Error cost is moderate. Two handoffs. It takes a full day each time, which is why it was raised, but twelve days a year is the ceiling on the benefit, and the report depends on data that is not yet clean.

B: copying orders into the fulfilment system. Runs around forty times a week. Fully deterministic. Error cost is high, since a wrong entry means a wrong delivery. Two handoffs, and one of them introduces a delay of several hours because it happens in batches.

C: deciding which overdue accounts to chase. Weekly. Not deterministic, because it depends on relationship context a person holds. Moderate error cost. One handoff.

B wins clearly. Highest frequency, unambiguous rules, high error cost, and a handoff that adds elapsed time. It will also surface the order-system integration question, which is the more valuable finding.

A looks attractive because it is a visible full day of work, but the annual benefit is capped and the data problem underneath it has to be solved first. C should not be automated at all; the useful move there is to put better information in front of the person, not to make the decision for them.

Who owns it afterwards

An automation is a small piece of production software. It has dependencies, it makes assumptions about input formats, and it will eventually break because something upstream changed. If nobody owns it, the failure mode is not that it stops loudly. It is that it keeps running and quietly produces wrong output.

Before the first automation goes live, answer three questions: who gets alerted when it fails, how you would tell that it failed silently, and what the manual fallback is while it is broken. If the honest answer to any of them is nobody, the automation has moved risk rather than removed work.

Sequence the roadmap around dependencies

Once the first one lands, order the rest by dependency rather than by appetite. Automating reporting before the data is clean produces fast wrong answers. Automating a downstream step while the upstream one still produces inconsistent input just moves the manual work.

Work upstream first. Clean input makes every downstream automation simpler and less brittle.

Plan for the exceptions

Every automated process meets input it was not designed for. The question is what happens next: does it stop and tell someone, or does it fail silently and produce a wrong result that surfaces weeks later?

Decide the exception path at design time. An automation that handles ninety percent of cases and clearly escalates the rest is worth far more than one that claims to handle everything and quietly does not.

The short version

• Score candidates on frequency, determinism, error cost, handoffs.
• Start where a person copies data between systems.
• Do not automate a process nobody can explain the same way twice.
• Question approval steps before speeding them up.
• Measure elapsed time before you change anything.
• Work upstream first.
• Design the exception path deliberately.

Yoddha Lab runs workflow automation as part of business process reengineering, which starts with process audit and mapping precisely so the first automation lands on the right process. Related reading: what business process reengineering actually is.