How to Automate a Business Process Without Breaking It

Step 1 — Map the process as it actually runs, not as the SOP says it runs

The written procedure and the process people actually follow diverge within weeks of being written, usually because someone found a faster path or a workaround for an edge case the SOP didn't cover. Automating the written version means automating a process nobody follows. Before anything gets built, watch someone do the task, or walk through the last ten real cases with them — not the ideal case, the last ten actual ones.

Step 2 — Find the exception path, not just the happy path

• What happens when the required field is missing, wrong, or arrives in the wrong format?
• What happens when two people touch the same record at the same time?
• What happens when the third-party tool it depends on is down or rate-limited?
• Who gets told when the exception happens, and how fast?

Step 3 — Decide what AI should touch, and what it shouldn't

AI business automation works well for drafting, classifying, and summarizing — pulling structure out of messy inputs for a human to approve. It works badly as the final decision-maker on anything with real consequences: refunds, contract terms, anything customer-facing that can't be quietly corrected after the fact. The pattern that holds up: AI drafts, a human approves, and the boundary between the two is explicit in the workflow, not assumed.

Step 4 — Build for the day it breaks

Every automation breaks eventually — an API changes, a field gets renamed, a volume spike hits a rate limit. The difference between an automation that survives and one that quietly fails for three weeks before anyone notices is whether it was built to fail loudly. That means error branches, not just happy paths, and a monitoring alert that fires the moment something stops working.

Step 5 — Assign a human owner, always

Automation without a named owner isn't automation — it's an unmonitored process that happens to run without a person clicking the button. Every workflow we build has one person's name attached to it, who gets the failure alert and is accountable for it working. 'The system handles it' is not an owner.

A worked example: automating new client onboarding

Take a common process: once a contract is signed, a new client needs a welcome email, a project set up in the delivery tool, an internal chat channel, an invoice for the deposit and a kickoff call scheduled. Done by hand, these steps get skipped or delayed whenever the team is busy.

Mapping the real process might show that the welcome email is customised for larger clients, that the deposit invoice depends on the payment terms in the contract, and that the kickoff call is often delayed because nobody knows the client's availability. Those are the exception paths. The automation handles the standard steps automatically, sends the customised email as a draft for the account manager to review, pulls payment terms from the signed contract, and includes a scheduling link in the welcome email so the client books the call themselves. Every failure alerts the operations owner.

How to tell if a process is ready to automate

• You can describe every step, including the exceptions, without saying “it depends” more than once or twice
• The process has been run the same way for at least a few weeks without changing
• The inputs arrive in a consistent format, or can be made consistent with a form
• You know what “done” looks like and can check it
• Someone has agreed to own it after it goes live

Measuring whether the automation worked

Before you build, write down what you expect to change: time spent per week, error rate, how long the process takes from start to finish, or how often a step gets missed. Measure the manual version for a couple of weeks first, even roughly. After the automation has run for a month, measure again. Without a baseline, “it feels faster” is the only evidence you will have, and that will not help you decide what to automate next.

Common mistakes when automating

• Automating a broken process, which just produces the wrong result faster
• Building one huge workflow instead of several small ones that are easier to understand and fix
• Hard-coding values like email addresses or prices that will change
• Skipping testing with real past examples, including the awkward ones
• Launching without telling the team what changed and what to do when it fails

Related reading