Automating Business Processes: A Step-by-Step Method That Holds Up

The most expensive mistake in automation is automating a process that shouldn't exist. It's also the most common, because writing down a bad process makes it look organized.

The method below has six steps, and the first three happen before you open any tool:

1. Pick a process worth automating — frequency first, not effort
2. Write it down as it actually runs — including the parts nobody admits to
3. Delete steps — this is where most of the value is
4. Split the work — rules, judgment, and human approval
5. Build the smallest version — one path, not all of them
6. Instrument it — including an alert for silence

Skip step three and you get a faster version of the same problem.

Step 1: Pick the right process

Score candidates on four things, in this order:

Frequency dominates. A daily process that takes four minutes is a far better candidate than a quarterly one that takes a day. Teams reliably pick the second because it feels more painful.

Step 2: Write it down as it actually runs

Not the documented version. The real one, with the spreadsheet someone keeps on the side and the message they send to check whether it's fine.

For each step, capture: who does it, what triggers it, what they need in order to do it, what they produce, and how long it waits before someone picks it up. That last field is where the surprise lives — most processes spend the large majority of their elapsed time queued rather than being worked on.

The output is a document, not a diagram. Documents are cheap to argue with. If you want a model for how to write the steps out, our set of workflow examples shows the level of detail that's actually useful.

Step 3: Delete steps before automating any

Four questions, applied to every step:

Has this approval ever resulted in a rejection? Pull the history. An approval with a 100% pass rate is a delay, not a control. Either remove it or raise the threshold until it starts catching things.

Is this information being re-entered? Every re-entry is a place two systems can disagree. Count them. The count is always higher than people expect, and each one is a candidate for elimination rather than automation.

Does anyone use this output? Reports get built for a meeting that stopped happening two years ago. Ask who reads it. If nobody can name a person, delete it.

Why does this wait here? Batching, a person's schedule, or a dependency. Batching is often removable at no cost.

Deleting steps is free and permanent. Automating steps costs money and creates maintenance. Do them in that order.

Step 4: Split the work three ways

This is the business process automation methodology that actually matters, and it's simpler than the frameworks suggest. Every remaining step is one of three kinds:

• Rules. Deterministic logic. "Under the threshold and matched, approve." Automate these first; they're reliable, cheap, and auditable, and tools like Zapier and n8n handle most of them without code. Where a system has no API at all, UiPath and other robotic process automation tools drive the interface directly instead.
• Judgment. Reading an unstructured document, classifying an intent, drafting a first version. These resisted business process automation for decades and are exactly what AI changed. They need review, not trust.
• Accountability. Someone signs off because someone must be answerable. Never automate these. Make them faster by giving the approver everything they need in one place.

Get the split wrong in either direction and the project fails: rules applied to judgment steps break on the first unusual input, and AI applied to rules steps is slower, costlier, and less predictable than an if statement. That distinction is the whole idea behind intelligent process automation.

Step 5: Build the smallest version

Automate the single most common path — what finance teams call straight-through processing. Not the variants, not the edge cases, just the one that covers most of the volume. The catalogue of shapes in our examples of automation is a useful place to find the version of your process someone has already built.

Everything else routes to a human queue, explicitly, with an owner. This is the step people skip, and it's the one that decides whether the automation survives: an exception with nowhere to go becomes an invisible backlog, and invisible backlogs are discovered by customers.

Run the automated path alongside the manual one for a couple of weeks and compare outputs. Disagreements are the specification you didn't know you needed.

Step 6: Instrument it, including the silence

Three things to watch, and the third is the one nobody sets up:

• Volume through each path. How much takes the happy path versus the exception queue. A rising exception rate means the process changed under you.
• Errors. Obvious, and the easy case, because errors announce themselves.
• Zero runs. The dangerous state. When an upstream field gets renamed, most automations don't error — they simply stop matching anything and run silently on nothing. Alert on an absence of activity, not just on failures. This one check catches more real incidents than error monitoring does.

A business process automation strategy, in four decisions

For automating across a whole company rather than one process, four decisions set the ceiling:

That last row causes more failures than any technical decision. Every automation needs a named owner who isn't the person who built it.

The gap between deciding and running

The method above is the easy half. The hard half is execution: connecting accounts, holding credentials, getting something to run reliably on a schedule without an engineer maintaining it.

If that's where your automation projects keep stalling, Taku is an AI-native desktop workspace built for exactly that gap — mirror a workflow someone already got working, point it at your own files, and keep it, without GitHub or environment setup. The free app library is the quickest way to see what's already packaged. Taku is in Beta, and the Mac app is available now.

FAQ

What are the steps to automate a business process?

Pick a high-frequency, stable process; document how it really runs; delete the steps that add nothing; split what's left into rules, judgment, and accountability; automate the most common path only; then instrument it — including an alert for when it stops running entirely.

What should you never automate?

Accountability steps, where a named person must be answerable for a decision. Anything irreversible without a human checkpoint. And any process that's still changing every few months — you'll rebuild the automation as fast as you build it.

How long does it take to automate a business process?

For a well-understood process with a clear trigger, days. What takes weeks is the discovery: finding out how the process actually runs, versus how it's documented. Teams that budget for the tooling and not the discovery are the ones that overrun.

What is the difference between automation and a business process automation strategy?

Automation is one process running without a person. A strategy decides which processes get automated, who owns them afterwards, what gets bought versus built, and how quality is kept consistent. Without one you get a scatter of automations nobody maintains.

How do you measure automation ROI?

Minutes saved times runs per year, minus maintenance hours times an hourly rate. Then add the effects that don't show up in either number: fewer errors, shorter cycle time, and work that no longer waits on one person's availability. Those second-order effects are usually larger than the time saved.

Do we need AI to automate business processes?

Only for the judgment steps — reading unstructured documents, classifying, drafting. The routing, thresholds, and scheduling that make up most of a process are ordinary rules, and rules are faster, cheaper, and easier to audit. Use AI where rules genuinely can't reach.