Business process automation is the use of software to carry a business process from request to outcome with as little manual work as possible. Stanford's 2025 AI Index, drawing on McKinsey's global survey, reports that 78% of respondents said their organizations used AI in at least one business function in 2024, up from 55% in 2023.
The harder question for operations leaders is how to turn AI use into processes that run reliably, at volume, with people still in control. The answer is a change in the unit of automation. Many automation programs have measured progress in tasks automated and bots deployed. With AI able to read, classify and decide, the unit worth automating is the whole process, with a person on the exceptions. That changes which processes qualify, how the work is done and who should do it.
What is business process automation?
Business process automation is software doing the work of a business process: receiving a request, checking it, acting on it in the systems of record and closing it. A process is a chain of steps that produces an outcome someone cares about, such as an activated service, a paid supplier or a corrected bill. Automation takes over steps in that chain.
BPA has been built in layers, each one covering work the previous layer could not.
- Workflow and business process management route cases between people and enforce the order of steps.
- Integration connects systems so data moves without retyping.
- Robotic process automation operates applications through their screens where no integration exists. IBM's explainer describes RPA as "rule-based software to perform business process activities at a high-volume."
- AI reads unstructured input, interprets it and makes routine decisions within policy, which is the layer that was missing. Judgment calls that need authority still belong to people.
Each earlier layer automated execution. None of them could decide anything a person had not already written down as a rule. That limit is one reason an automation program can plateau: the steps left manual are the ones that need reading or interpretation, and in an important process those steps often sit in the middle.
There is an older lesson in the history too. In 1990 Michael Hammer argued in Harvard Business Review, under the title "Reengineering Work: Don't Automate, Obliterate," that companies were using technology to speed up processes that should not exist. Business process reengineering became the discipline of redesigning first. It applies with more force now, because AI makes it tempting to automate everything as it stands.
What changed when AI arrived?
AI moved the boundary of what can be automated from steps that follow rules to steps that need interpretation. The consequence is that a whole process, not a slice of it, can now be the unit of automation.
| Generation | Unit of automation | Handles | Breaks on | Who handles exceptions |
|---|---|---|---|---|
| Workflow and BPM | The route between people | Assignment, sequence, deadlines | Anything that needs doing, not routing | Everyone, since people do the work |
| Integration | The data handoff | Structured data between systems | Missing or malformed data | IT, when something fails |
| RPA | The task | Fixed clicks and keystrokes | Screen changes, unstructured input | An error queue nobody owns |
| AI-powered RPA | The task, with a model | Documents and free text at specific steps | Cases that need the whole picture | Unclear, often the bot's builder |
| Whole-process AI system | The process, end to end | Routine decisions, execution, records | Rare and high-risk cases, by design | A named person with full context |
The terms used for these generations overlap. Intelligent automation, which IBM describes as combining AI, business process management and RPA "to streamline and scale decision-making across organizations," is the broad label. AI-powered RPA is the narrower move of adding models at the steps where bots fail. An intelligent workflow is the orchestration layer that lets software make decisions inside a workflow. The AI vs automation comparison explains the underlying split between rules and judgment, and RPA vs intelligent automation applies it to the choice of tools.
Two consequences follow from the change.
First, the processes worth automating are different. The best candidates used to be the most rule-bound. Now they include the most valuable: billing disputes, order fallout, supplier exceptions, processes that combine high volume with constant interpretation.
Second, the design problem moves. When a system makes decisions, the hard question is no longer how to script the steps. It is which decisions the system owns, how sure it must be before acting, and what a person sees when a case comes to them. The exception path stops being an error queue and becomes part of the product.
Which processes should you automate first?
Start with one process. A program that starts from a long list of candidates risks producing many small automations and no process that works differently end to end.
The best first process has three traits at once. It is too important to stay manual: delays cost revenue, customers or compliance. It is too specific to your business for packaged software, because it runs across your own mix of systems, contracts and rules. And it is too complex for basic automation, because inputs are messy and some cases need judgment. A process with only the first trait may be better served by a SaaS tool. A process without the third trait may only need RPA.
Then score it against the seven questions in the AI for business operations guide: volume, cost of failure, written rules, measurability, one owner, reachable data and identifiable exceptions. Two of them settle most arguments. Without one owner in operations who answers for the outcome, nobody can run the result. Without a measurable baseline of cycle time, backlog, rework, cost per case or error rate, nobody can show it worked.
Evidence beats opinion when choosing. Process mining reconstructs how a process actually runs from the event logs of its systems, and process intelligence keeps that picture current with business context. Both show which variants carry the volume, where cases wait and where they loop back. Neither sees the email, the phone call or the spreadsheet, so pair the data with time alongside the team. The process mining vs RPA comparison sets out why seeing comes before doing.
At company scale, choosing and governing many processes is an operating model question, the subject of enterprise automation. But each process still gets automated one at a time.
How do you automate a whole process with AI?
Manthle's engineers use a five-step method, and the AI implementation guide lays out the five steps. Applied to business process automation, it looks like this.
See. Build a factual picture of the process: the event data, the variants, the volumes, the time spent and where, and the decisions people make repeatedly. Sit with the people who do the work, because the most important part of a process is often the part no system records.
Rethink. Redesign before automating. Remove the steps that exist only to move data between people, capture information at the start that is chased later, and decide which decisions belong to a model, which to rules and which to a person. Process redesign covers the discipline, including what changes when part of the worker is a model.
Engineer. Build the system around the redesigned process: models where messy input needs interpretation, rules where a rule will do, integrations into the systems of record and an exception queue inside the tools the team already uses. Some steps may suit an AI agent that plans and uses tools; the AI agents for business guide covers what an agent can own and what it must hand off.
Harden. Test against the cases that break things: malformed inputs, slow systems, rare variants, adversarial requests. Add confidence thresholds, limits on what the system can change on its own, approvals for actions that are hard to undo, and a full audit trail.
Run. Operate the process after launch. Monitor accuracy by sampling, watch the age of the exception queue, notice when the input mix shifts and adjust. A process automated with AI is not finished at go-live, because its inputs keep changing.
A pilot on one process makes all five steps concrete. It runs on real cases against measures agreed before the build, and at Manthle a pilot that meets its measures becomes a monthly operations contract.
Pick the measures from the baseline the See step produced, and keep them few. For most processes, a COO needs to read four numbers each week:
- Straight-through share: the proportion of cases closed with no person touching them.
- Decision accuracy: the error rate in a weekly sample of automated decisions, checked by a specialist.
- Cycle time: from request to outcome, against the pre-pilot baseline.
- Exception health: how many cases wait for a person, and how long the oldest one has waited.
A rising straight-through share with falling accuracy is a warning, not a win. A short exception queue with old cases in it means the handoff is not working. Read the four together.
What does the person on the exceptions do?
The person on the exceptions is the part of the design most programs skip and the part that decides whether the process works.
In a whole-process design, people stop doing every case and start doing three things. They decide the cases the system routes to them: the low-confidence classification, the high-value adjustment, the request nobody has seen before. They review samples of the cases the system decided alone, which is how accuracy problems surface before customers find them. And they improve the process, by telling the engineers which rules are wrong and which new class of case the system could take on.
That role only works if the handoff is designed. A case that reaches a person should arrive with the input, the relevant history, the system's proposed decision and its reason, all in one view inside the tool the person already works in. If people have to reassemble the context themselves, the automation has moved work instead of removing it. The AI for business operations guide sets out the four kinds of work that stay with people once a process is rebuilt.
A workflow built this way is what AI workflow automation means at Manthle: one critical workflow, engineered and run, with people kept on what needs people.
Who should do the work: tools, partners or your own team?
The honest answer depends on the process.
Buy a tool when the process is common across companies, the inputs are clean and your team can own the configuration. Workflow and automation platforms are the cheapest route for that kind of work.
Hire an RPA partner when the steps are fixed, inputs are structured and you need many small automations on one platform quickly.
Use a strategy firm when the question is a portfolio across every function and a multi-year plan.
Build in-house when you have an automation team with AI engineering skills and the capacity to run what it builds.
Use an operated model when the process is critical, specific to your business, varied and costly when late, and you want it built and then run. Three pages describe how Manthle runs this model from different angles: business process automation services from the process side, intelligent automation consulting for buyers who came looking for advice, and AI automation services set against the agency model.
Whichever route you take, ask the same questions of whoever builds it. Will they look at the process in data before designing? Which steps will they remove? Who handles the cases the system cannot decide, and what will that person see? Who runs it after launch?
A practical first move costs nothing: name the one process in your operation that has all three traits, pull a few months of its event data and look at where cases wait and loop. The case for automating it, or for leaving it alone, will be in that data.