Automation

Automation is software carrying a repeatable job through steps you defined, from whatever starts the work to a result you can check. It doesn’t have to use AI, and if ordinary rules can do the job, I’d start with those.

A model helps with steps that involve language, images, or variation that’s hard to handle with fixed rules. The questions around it stay the same, who starts the run, who chooses the next step, and what proves the work finished.

Across the 150+ franchise units in the delivery data I review, roughly 80% use chatbots, 15% run rigid workflows that start on triggers, and 5% run autonomous agents defined by conditions. Those are different ways of organizing the work, not just different tools to buy.

What does business automation include?

Business automation covers the full path from the event that starts work to the record that proves it finished. A trigger by itself does not complete a process.

Microsoft describes three common ways its cloud flows start, an event starts an automated flow, a person presses a button to start an instant flow, or a scheduled flow starts at a set time. From there, the flow runs actions chosen in advance.

Take new-client intake, where a signed agreement starts the run. Rules create the account, open the project, assign the delivery owner, copy the approved scope, and create the first deadline, then a final check confirms that all those records point to the same client and agreement.

The workflow also needs an exception path. A duplicate account, missing scope, failed write, or unknown delivery owner should stop in a visible queue. The run record should show what finished, what failed, and who owns recovery.

Before you build, use those parts as a checklist:

• Trigger: the signed agreement enters the approved folder and starts the work.
• Input: the signed agreement and approved scope supply the facts.
• Actions: the system creates the account, project, owner, and deadline in the agreed order.
• Check: every record points to the same client and scope.
• Exception: a duplicate account stops the run and goes to operations.
• Owner: the process owner receives the failed run and knows what to do next.

If your team can’t fill in one of those parts, decide it before handing the job to software.

What is the difference between automation and AI automation?

Ordinary automation applies known rules to predictable inputs. AI automation adds a model to a step where language, images, or variable input makes those rules hard to write.

In a shared intake mailbox, rules can save a message, match the sender to a client, create a ticket, and set a due date. A model can read the different wording clients use, classify the request, and draft a summary, then another rule can send it to the right place based on that category.

In an AI workflow, the model handles an uncertain step while the surrounding path remains fixed. Using a model to copy a known account number from one system to another adds variation to a step that already has a clear rule.

The model does not remove the source, check, or exception owner. It changes the kind of input the workflow can handle. If the message contains a scope change or a promise to a client, the system should send the decision to a person before acting.

When is a workflow better than an AI agent?

Use a workflow when the path can be drawn before the run begins. Use an AI agent when the next action depends on information discovered during the work.

Anthropic’s December 2024 guidance defines workflows by predefined code paths and agents by their ability to choose their process and tools as they go. It recommends starting with the simplest design that works because more autonomy adds cost and can let errors build on each other.

With fixed automation, you mostly maintain the connections and rules for exceptions. Add AI inside a fixed workflow and you also need to test what the model produces and decide where uncertain results go.

An agent adds another job, keeping track of its choices, permissions, and how to recover when only part of the work is done. Where the result is hard to check or the action is hard to reverse, a qualified person still needs time to decide.

A proposal workflow usually has a known path. It collects the approved transcript, matches the account, extracts requirements, drafts the proposal, sends price review to a person, and files the final version. A support investigation may need an agent because the next step depends on what the first system reveals.

Use that flexibility only when the firm can still test the outcome, stop the run, and recover partial work. A longer path gives more places for a wrong decision to travel.

What should a business automate first?

Start with one repeated handoff that has a clear source of truth and a visible completion record. Intake, document routing, recurring reporting, and status collection are common candidates because they happen often and leave inspectable records.

Write the current path before choosing a tool. Name the trigger, approved inputs, actions, reviewer, exception, and final record. Test five cases: a normal run, missing information, a duplicate record, a tool failure after one write, and a consequence that requires approval.

Watch enough real runs to find the exceptions people handle from memory. The person doing the work may know that one client uses two account names or that a signed change order outranks the original scope. If that judgment stays unwritten, the system may follow a record that looks complete but doesn’t contain the rule the person was using.

I’d finish one workflow before opening the next, rather than start six at once. Watch it in production, fix how it handles exceptions, and check that the final record is correct.

What breaks after an automation launches?

Automations often fail through partial work. One step succeeds, the next times out, and two systems now disagree about the client.

Access can expire, an API can slow down, someone can rename a field or move a spreadsheet column, and a retry can create the same record twice. If there’s AI in the workflow, it can also receive an unfamiliar document and put it in the wrong category with no sign of doubt.

For each case, you need to know what already happened and how someone can recover the unfinished work.

Under Microsoft’s current flow limits, some plans allow a flow with continuous errors to be turned off after 14 days, and an inactive flow to be suspended after 90 days. Those are Microsoft product rules, not universal limits on automation.

They give you one reason to keep watching after launch, because software that ran yesterday can stop when the system around it changes.

NIST’s AI Risk Management Framework Core treats production monitoring as ongoing work. It calls for oversight roles, production monitoring, and post-deployment plans for override, incident response, recovery, and change management. Those duties need an owner after launch.

Where should a person stay in the workflow?

Keep a person before an action whose consequence is expensive to check or hard to undo. That usually includes money, scope, a promise to a client, permission changes, deletion, and work where source records conflict.

Give the reviewer what they need to decide, the source, proposed action, rule that caused the stop, and what happens after approval. If they have to rebuild the case from five systems, you haven’t removed that part of the manual work.

NIST notes in its human-AI interaction appendix that some systems may not require human oversight. It also says operational uses need clear human roles and responsibilities. The boundary depends on the situation and the consequence.

That approval step keeps the decision with a person, so write down which decisions need it and who receives them.

This is also why automating a task doesn’t tell you a whole job can disappear. The International Labour Organization assessed nearly 30,000 tasks in May 2025 and found that one in four workers worldwide held an occupation with some generative-AI exposure, with changes to jobs more likely than full replacement.

Exposure isn’t a count of jobs replaced. Work can contain steps software handles alongside decisions that stay with a person.

How should a firm measure automation?

Measure the finished business record before measuring time saved. Track completion, defects, review time, exception rate, cycle time, and duplicate or conflicting writes.

Then decide where the recovered capacity goes. A task can run in two minutes instead of twenty while the employee spends the difference checking errors or waiting on the next approval. The automation moved cost into another queue.

Checking is something you can work on too. In one week of output across many projects in a franchise network’s delivery data, more than 300 generated pieces showed roughly 95% fewer pieces marked as containing incorrect information or data after tuning, compared with the same system as first implemented.

The checking layer used online fact checks, checks against client data, rules for recurring errors, and guardrails for repeated language and logic failures. That result is about the combined system and those outputs, not the accuracy of one checker or a benchmark for another firm.

The useful point is that review can be measured and improved, so count it as part of the work rather than leave it out of the saving.

Where does automation sit on the Delivery Model Ladder?

Automation belongs mainly at Stage 2, Augmented, on the Delivery Model Ladder. The workflow starts from a defined event, carries work across systems, checks the result, and routes exceptions to a named person. The firm has changed how delivery runs.

At Stage 1, Enhanced, a person may push the button, inspect every result, and copy it into the next system. The tool makes that person’s task faster while the surrounding workflow stays the same.

At Stage 3, AI-native, larger parts of delivery can start from conditions and run across shared company systems. More work happens without a person assembling every input or handoff. Testing, monitoring, and recovery matter more because one failure can travel farther before a person sees it.

The gap between a working demonstration and an owned operating system belongs to the Production Gap. Automation closes part of it when the trigger, checks, exceptions, and recovery owner travel with the work.

When should a process stay manual?

Keep a process manual when it is rare, changes faster than the system can be maintained, lacks an authoritative source, or ends in a consequence the firm cannot test and reverse. Automation assumes someone can define correct completion.

Before building, write down what starts the run, which record supplies the facts, what proves completion, where it must stop, and who recovers a failure. If you can’t answer one of those yet, document that part of the work before automating it.