Business Process Automation: What to Automate, What to Leave Alone and Where Governance Belongs

The short answer

Business process automation means letting software handle the recurring standard cases of a clearly defined process: capturing, checking, routing, handing over and recording information. It works when four things are settled first: what the process has to deliver, what each case is worth, who owns the outcome and which decisions stay with people. The biggest return rarely comes from full automation. It comes from an 80% solution in which standard cases run automatically and exceptions and critical decisions stay with humans.

Technology is rarely the bottleneck. A workflow in n8n or Make takes an afternoon, Power Automate already ships with Microsoft 365, and AI applications can act on CRM, ERP or ticketing systems through MCP servers. Automation projects still disappoint, and almost always for the same reason: the team automated something that was never really a process.

Why business process automation usually fails

Most automation initiatives start with a task, not a process. “Invoice entry takes too long.” “Leads need to get into the CRM.” “Faxes need to be digital.” These are valid triggers, but they describe activity, not a process.

A process includes the decision rules, the people accountable for the result and the boundaries it must operate within. When that knowledge lives only in experienced employees’ heads, the work gets done because people improvise. Automation does not improvise. It executes exactly what it is told, the same way every time. The typical symptoms follow: the workflows run, yet exceptions pile up in shared inboxes, errors surface late and nobody feels responsible.

That is why sequence comes first: a grown workflow is simplified and standardised before it is automated. How to do that first step is covered in How to Streamline Business Processes. If your process is not yet clearly defined, start there. This article picks up afterwards and answers the next question: what exactly should you automate, and how do you stay in control?

A readiness test: four questions before you automate

Before anyone builds a workflow, the process should be able to answer four questions. If one of them stays open, it is not ready for automation.

Most companies ask the first two questions. The last two are often skipped because they force organisational decisions. That is exactly where automation projects break later, and exactly where the 80% rule comes in.

Not when, but what: the 80% rule

The usual question is when automation becomes worth it. The better question is what to automate. Standard cases always follow the same path, can be decided by clear rules and do not collide with governance or compliance. They often make up most of the volume but little of the complexity. Exceptions are rarer but consume a disproportionate share of effort. Trying to automate them too usually produces more special-case logic than value.

A simple matrix makes the decision explicit:

The most underrated cell is “detect and route”. Good automation does not need to solve every case. It does need to recognise reliably when a case does not fit, and hand it to the right person with full context. That handover is part of the process design, not an error state.

Business process automation example: from paper fax to the core pharmacy system

What this looks like in a business-critical process is shown by a project for a pharmacy group in western Germany that supplies care facilities and medical institutions and produces patient-specific medication blister packs.

Around 500 documents arrived by fax every day, on paper: prescriptions and correspondence from doctors, care homes, hospitals and nursing homes. Each one had to be read, matched to the right case, processed and archived in a traceable way, manually and under high demands on reliability and availability. Approximately 40 users worked in this process. Fax was not a relic. It was part of the operational backbone.

The obvious brief would have been to receive faxes digitally and archive them. That would have turned paper into PDFs and changed little about the actual work. Instead, the process was mapped digitally first: where does a document come from, which case does it belong to, who handles it, what happens next and what evidence is required? Only then was it automated and integrated:

Faxes arrived digitally via Placetel and T-Online, with Easybell as a backup. On top of that sat a bespoke Laravel web application: Google Vision recognised the text and a machine-learning model matched each document to the right patient. Because one fax often contained several documents, a dedicated tool split it into individual documents. Medication plans, prescriptions and correspondence then moved through a Kanban workflow, and finished documents were passed through an interface to adocu, NOVENTI's document management system. Patient and institution data, such as hospitals and care homes, arrived every night as a batch export from prokas. The result: around 500 documents a day now run through one end-to-end digital process, and manual workload fell by around 3.5 FTE. What made the difference was not the text recognition or the software. It was the sequence: process first, then integration, then automation.

Starting point, architecture and delivery in detail: Case study: process and system architecture for digital pharmacy operations.

AI business process automation: where does the governance layer sit?

AI changes the question. Classic workflows execute fixed rules. AI applications interpret documents, draft responses and can trigger actions through APIs on their own. That expands what can be automated considerably, and it blurs who is actually deciding.

Many organisations now want to work with AI, and they should. What is often missing is a deliberate decision about where the machine suggests and where it acts. That governance layer between people and machines belongs before AI is connected to production systems, not after:

• Decision rights: which actions may the AI execute on its own, and which may it only prepare?
• Approval points: where does a person confirm before anything leaves the company or data is changed?
• Permissions: which systems and data can the application reach, and with whose rights?
• Audit trail: can you trace what the AI did, when and on what basis?
• Accountability: who is responsible when an automatically generated result is wrong?

This is the 80% rule applied to AI: on standard cases AI may act, exceptions it should detect, and on critical cases it supports people instead of deciding. How AI connects marketing, sales and customer success through one shared control logic is described in GTM Control Plane.

What about tools? Secondary, but not irrelevant

The right tool depends on your systems landscape, your data protection requirements and who will run the automation long term. And on how well it lets you implement the governance from the readiness test:

• n8n: flexible workflow automation that can be self-hosted, useful when data has to stay in your own infrastructure.
• Make: a visual platform with many ready-made connectors for fast integration between cloud applications.
• Power Automate: the natural choice in Microsoft 365 and Dynamics environments, where permissions and data already live.
• MCP servers: through the Model Context Protocol, AI applications operate systems and processes directly. Here the governance layer is mandatory, not optional.
• Custom development: worth it for business-critical, high-volume processes that must integrate deeply with specialist software, as in the pharmacy example.

No tool replaces the readiness test. Teams that have answered the four questions can succeed with almost any of these tools. Teams that skip them fail with all of them.

Off-the-shelf workflows stop being enough once high volume, several specialist systems and compliance requirements come together. At that point the path runs through a deliberate solution architecture and custom development that integrates with the existing systems landscape, as in the pharmacy case.

How to automate business processes in five steps

The readiness test, the 80% rule and the governance layer add up to a clear sequence:

• Map the real process, including exceptions, workarounds and the systems people actually work in.
• Run the readiness test: settle requirements, cost and value, ownership and governance.
• Cut the 80%: separate standard cases, exceptions and critical cases, and define the handover point to people.
• Integrate rather than bolt on: the automation works inside existing systems, not as another isolated tool.
• Measure and refine: track the share of cases handled automatically, the exception rate and errors, and adjust the rules.

Business process automation FAQ

Process first, then automation

If you want to automate business processes, do not start with the tool. Start with three decisions: is this workflow really a process, which 80% are standard and non-critical, and where exactly does a person decide, especially once AI is involved? Once those are answered, the technical build is usually the smaller part of the work.