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.

Related reading