How to decide which business processes to automate

The hardest part of automating a business isn't the building. It's choosing what to build first. Pick the wrong process and you sink weeks into something that touches three people once a month. Pick the right one and the same effort pays back every single day.

So before any code gets written, the real question is: which business processes should you automate, and in what order? Here's how we decide.

Start with how work moves, not where the AI would be cool

The instinct is to look for the process that would be most impressive to automate. That's backwards. The processes worth automating are almost always the unglamorous ones: the repetitive, high-volume handoffs where information gets moved from one system to another by a person who'd rather be doing literally anything else.

If your team is re-keying the same information between tools every day, that's not a workflow. That's a queue waiting to be automated.

To define which business processes to automate, map how work actually flows through your operation, then look for the steps where a human is acting as glue between two systems that should have been talking to each other. Those handoffs are where the time goes, and where automation compounds.

The four-part test for what to automate first

A process is a strong automation candidate when it scores well on four traits. The more of these it has, the higher it should sit on your list.

1. Repetitive. The same steps happen over and over, in roughly the same order. If it only happens once a quarter, automating it rarely earns back the build.
2. High-volume. Volume is what turns a small per-task saving into a real one. Ten minutes saved on something that happens twice a year is noise. Ten minutes saved on something that happens fifty times a day is a hire's worth of capacity.
3. Rule-based. The decisions inside it follow logic you can write down: if the amount is over X, route to Y; if the form is missing a field, send it back. Clear rules mean the work can run the same way every time, deterministically, with no model required.
4. A cross-system handoff. The step exists only because two tools don't talk. Copying a record from the CRM into the accounting system, retyping an approved quote into the project tool, reconciling a spreadsheet against an inbox. These are pure friction, and removing them is pure gain. (This is the substrate problem we wrote about here.)

Score your processes against those four. The ones that hit all four are where you start. The ones that hit none are usually judgment work that shouldn't be fully automated at all.

What automates a business process, in practice

When people ask what actually automates a process, the honest answer is mostly not AI. It's deterministic engineering: a rule that fires on a condition, a record that syncs across systems, a document that generates and files itself, an approval that routes on an amount threshold. That's the spine of almost every system worth running.

AI enters later, and narrowly: reading an unstructured document, classifying a free-text request, drafting a reply for a person to approve. It's a component inside the workflow, not the workflow itself. (Why deterministic-first beats AI-first.)

This is the order that holds up: unify your systems, automate the deterministic handoffs, then add structured AI only where genuine judgment lives. Skip straight to "put an AI on it" and you're automating on top of a process that was never solid to begin with.

Don't automate a broken process. Fix it, then automate it.

A tempting trap: take a messy, manual process and wrap automation around it exactly as it is. All you've done is make a bad process run faster. Before you automate, it's worth asking whether the process should exist in its current shape at all, or whether half its steps are workarounds for tools that don't share data.

This is why we unify first. When the CRM, the accounting system, and the documents live on one source of truth, a lot of the "process" you were about to automate simply disappears, because the handoff it existed to bridge is gone. Automate what's left, and you're automating something real.

Sequence: smallest real slice, highest daily payback

Once you've found the candidates, don't try to automate the whole operation at once. Pick the process with the highest daily volume and the clearest rules, scope it small and real, and ship it. A working slice that runs every day beats a sweeping plan that dies in committee.

That ordering, smallest real slice first, is the same one we use on every engagement. It's how you get working software in weeks instead of a roadmap that never lands. (Here's how we work.)

The short version

To choose what to automate: map how work moves, find the repetitive high-volume handoffs that follow clear rules, fix the process before you wrap it, and start with the smallest slice that pays back every day. Save AI for the steps that genuinely need judgment, and let rules do the rest.

That's the work we do. If you want a candid read on which of your processes are worth automating first, and which just need your systems to start talking, the consultation is free. We'll tell you straight, including when the answer is to fix the foundation before automating anything.