An automation is a work instruction for a machine, and the machine carries it out exactly as written. A person who gets an incomplete instruction asks, improvises or remembers how it went last time. An automation does exactly what it was told, and with everything else it either stops or carries on with a wrong assumption.
The tools for this are mature, and many are already built into existing software. What carries an automation project in a mid-sized company is a precise description of what the process does, including the exceptions an experienced employee handles without thinking. This guide shows which methods of process automation exist, which processes are suitable, how to calculate the business case in full, and which steps to follow.
What Process Automation Is
Process automation means that steps of a business process run without human involvement: an invoice is assigned to the right cost center according to fixed rules and forwarded for approval, an order automatically triggers an order confirmation, a new employee automatically receives their accounts on day one.
The prerequisite is a digital process. As long as a step happens on paper, the most you can do is photograph it. That is why process digitization almost always comes before automation: the workflow first runs end to end in the system, and then the system can handle it on its own.
Responsibility stays with people. Automation takes over steps, and someone knows what it does, keeps an eye on it and steps in when it gets things wrong.
Process Automation Methods Compared
"Process automation" covers very different techniques. Five are relevant for mid-sized companies, and they differ mainly in how reliably they run and who can maintain them.
| Method | How it works | Good for | Weak spot |
|---|---|---|---|
| Workflow features of existing software | Rules and approvals in the ERP, document management system or office suite | Approvals, routing, notifications | Often unused because nobody knows they exist |
| Integration via interfaces | Systems exchange data via APIs, for example through an integration platform or low-code tool | Keeping data in sync between shop, ERP, CRM and accounting | Needs interfaces on both sides |
| Robotic process automation (RPA) | A software robot operates user interfaces like a person: click, copy, paste | Legacy systems without an interface | Breaks with every change to the interface |
| Document processing with AI | The AI reads receipts, emails and forms and extracts structured data | Incoming invoices, delivery notes, orders by email | Needs check rules for uncertain results |
| AI agents | A language model decides on next steps itself and calls tools | Preparation and research with human approval | Hard to predict, hard to verify |
As a rule of thumb: as far down the table as necessary, as far up as possible. An approval rule in the ERP looks unremarkable, yet it runs for years without maintenance. An RPA robot clicking through an old interface looks good in a demo and needs adjusting after every update. An integration via interfaces usually copes with change better than a robot operating a screen.
Digital and AI-Powered Process Automation
"Digital process automation" usually means the combination of the first two rows: processes run digitally end to end, systems are connected, approvals and routing follow fixed rules. That is the solid core of any automation and, in mid-sized companies, the biggest lever.
AI process automation extends this to steps that used to need a person because language or unstructured documents were involved. The AI reads the order from the email, assigns the complaint to a category and recognizes that a delivery note belongs to a particular order. This way you can also automate processes that begin with an unstructured input.
In return, you accept a degree of uncertainty. A rule delivers either the right result or none, an AI delivers the right result with a certain probability, and a wrong result looks exactly like a right one. AI components therefore always get a check rule: below a confidence threshold a person takes a look, data is reconciled against master data, and under Article 22 GDPR decisions with legal effect on individuals may not, as a rule, be based solely on automated processing. More on use cases and limits in AI process optimization.
Which Processes Are Suitable for Automation
Five criteria show whether a process is a good candidate:
- Frequency: does the process run daily or weekly? A workflow that runs four times a year rarely carries the effort of building and maintaining an automation.
- Rule-based: can every decision in the process be expressed as a rule, or at least the vast majority? Where the answer is "it depends", a person keeps making the call.
- Stability: is the process changing right now? Automate processes whose ownership and workflow are settled.
- Digital input: does the data arrive digitally, or does someone first have to type or scan something?
- Documentation: is the process described well enough that someone who has never done it could carry it out, including the most common exceptions?
The last criterion deserves the most effort, because every automation has to know every branch. Someone who has run a process for twelve years usually describes the normal case in three sentences, and the eleven exceptions come to mind as they happen. It helps to ask about them deliberately before building.
Good starting candidates in mid-sized companies are therefore often: incoming invoices and approval, order confirmations, data reconciliation between shop and ERP, creating accounts when new employees join, reminders for inspection and maintenance deadlines, and standard reports that someone currently copies together from three spreadsheets every Monday.
Why Automation Needs Documentation
Three patterns come up again and again in automation projects, and all three relate to documentation.
The automated exception. The automation covers the normal case. When an exception occurs that nobody described, such as the customer with a different billing address, the partial delivery or the credit note instead of an invoice, the case ends up in the error folder or gets processed incorrectly. Employees then double-check everything to be safe, and the time gained goes into checking.
The automated detour. If a process is automated as it is, its detours get automated too: the double approval nobody needs, or the export into a spreadsheet that only exists because the ERP could not produce a report years ago. A detour becomes a hard-wired step.
The automation as a knowledge silo. Whoever built the automation knows how it works. Often that is a single person, the tech-savvy colleague from purchasing, the working student or the external service provider. When that person leaves, the knowledge of why the robot sends a spreadsheet every Monday at six a.m. leaves too. The automation's bus factor is one, and it is less visible than a person's because the automation runs quietly in the background.
The answer is the same every time: capture the process with all its exceptions beforehand, simplify it before automating, and document the automation itself like any other process, with an owner, a stand-in and a work instruction for when it fails.
Calculating the Business Case in Full
Many calculations count the minutes saved and leave out the rest. A complete calculation has four items:
Savings per year = frequency per year × minutes saved per case × hourly rate ÷ 60
Setup = analysis and documentation + configuration + testing + training
Running costs per year = licenses + maintenance and adjustments + checking the exceptions that are still handled manually
Risk = what does an error cost that the automation repeats unnoticed?
A worked example with deliberately round numbers: 3,000 incoming invoices a year, 4 minutes saved per invoice through automatic reading and routing, an hourly rate of €45. That is 3,000 × 4 × 45 ÷ 60 = €9,000 a year. From that you subtract license costs and the time for invoices that are still checked by hand. With one fifth exceptions and 6 minutes of checking per exception, that is 600 × 6 × 45 ÷ 60 = €2,700. The calculation works, with much less headroom than the first figure suggests. Plug in your own values and make sure all four items appear.
The biggest swing in this calculation is often the exception rate, and you know it once you have captured the process beforehand.
Process Automation in Six Steps
Step 1: Collect candidates and capture the as-is process
Collect candidates from daily work: where do people re-type, copy, remind, forward? For the most promising ones, capture the current process. Talk to several people involved and ask explicitly about exceptions, such as the most common special case and the strangest case last year. The methods are covered in as-is process mapping.
Step 2: Simplify the process before automating it
Remove steps nobody needs, combine approvals and clarify responsibilities. A process analysis shows where the detours are, and the process optimization guide describes methods such as Lean and value stream mapping for improving the workflow. Every step you remove here drops out of building, testing and maintenance.
Step 3: Choose the method - as simple as possible
First check whether existing software can already do the step, then look at interfaces. RPA fits when there is no interface and the legacy system will stay for years. Use AI for the steps that handle unstructured input, and always with a check rule.
Step 4: Test deliberately with the exceptions
Test the automation with real cases and deliberately with the exceptions from step 1. Decide what happens to cases the automation cannot process: who gets them, how quickly, and how do they recognize them? An error folder works when someone looks at it regularly.
Step 5: Organize operations
Every automation gets a business owner, a stand-in and monitoring: is it still running, how many cases go into the exception path, has the rate changed? In Germany, involve the works council before rollout. It must be informed about and consulted on the planning of workflows including the use of AI under section 90 of the Works Constitution Act (BetrVG), and systems that are objectively capable of monitoring performance or behavior are subject to codetermination under section 87(1) no. 6 BetrVG.
Step 6: Update the documentation
Describe the new process: which steps the automation performs, which are still done by people and what happens in case of failure. This description spreads the knowledge from the previous section across several people and is the basis for adapting the automation in two years.
Example: A Machining Supplier With 80 Employees
Composite example: it combines workflows and findings that are common in manufacturing companies of this size. The company and the figures are a worked example, not a customer project.
A supplier of turned and milled parts, 80 employees. The commercial director wants to automate order confirmations: orders arrive by email as PDFs, are entered into the ERP, and the confirmation goes out after one to two days. The plan is a tool that reads the PDF orders and sends the confirmation automatically.
Capturing the process through conversations in inside sales, production planning and with the production manager shows where the time goes. Entering the order into the ERP is quick. Before confirming, however, inside sales checks the delivery date by calling production planning, which keeps the actual machine schedule in its own spreadsheet while the ERP only knows the planned one. For new parts, production planning also checks with the production manager whether the material is in stock. A third of orders contain drawing revisions that have to be checked.
An automation that confirms immediately would therefore have promised delivery dates nobody had checked. So this is what was implemented: the actual machine schedule is now maintained in the ERP rather than the spreadsheet. Repeat parts with a known drawing revision run through automatically, from reading the order through checking the date against the schedule to a draft confirmation for approval. New parts and changed drawing revisions still go to a person, now with all the information bundled. The automation is smaller than planned and runs reliably.
Where wissa.ai Fits
wissa.ai is neither an RPA tool nor a workflow engine. It delivers what every automation needs first: a description of the process as it really runs, including the exceptions that come up in conversation.
An AI interviews your employees via chat in conversations of roughly 15 to 20 minutes, whenever it suits them. It follows up where an answer leaves gaps: what happens when the information is missing? Who does this when you are away? In which system, and what happens next to it? When further people are named in the conversation, it suggests inviting them next. That is how production planning and its spreadsheet come into view before the automation is built. How this works in detail is described in AI process documentation.
The conversations produce process documentation, an overview of all areas and processes as the basis for a process map, a tool register and the findings that matter for an automation: manual handoffs, duplicate work, knowledge silos and contradictions between people, each with a source. After the switch you run a new conversation, and the documentation continues with a diff against the previous version. The application is hosted in Germany, with AI processing in the EU, a data processing agreement under Article 28 GDPR is included (contract documents in German), and it is best to bring the works council in from the start.
A free test package to get started (10 credits, once per company, terms) is usually enough for a first interview, and we would be glad if you tried it with a process you would like to automate.
Conclusion
Process automation pays off in mid-sized companies where processes are frequent, rule-based, stable and digital, and above all where they are fully described. Many workflow features already sit in existing software, interfaces cope with change better than robots, and AI extends automation to documents and language when check rules accompany it. Most of the work lies in the exceptions. If you capture the process with everyone involved beforehand, simplify it and document it afterwards, you build automations that keep running long after the person who built them has moved on to other tasks.
FAQ
What is process automation?
Process automation means that steps of a business process run without human involvement, such as routing an invoice for approval, sending an order confirmation or reconciling data between two systems. The prerequisite is a digital, documented process with clear rules.
What is the difference between RPA and process automation?
RPA (robotic process automation) is one method of process automation: a software robot operates user interfaces like a person. Process automation also includes workflow features in existing software, integration via interfaces and AI-powered document processing. RPA fits when a legacy system has no interface, and it needs adjusting more often after interface changes than an interface-based integration.
What is AI process automation?
AI process automation uses artificial intelligence for steps that used to require language understanding: reading data from documents and emails, classifying requests, producing drafts. Because AI results can be uncertain, these steps get check rules, such as a human review below a confidence threshold or reconciliation against master data.
Which processes are suitable for automation?
Processes that occur frequently, can be described as rules, are stable, have digital input and are documented. In mid-sized companies these are often incoming invoices, order confirmations, data reconciliation between systems, accounts for new employees and recurring reports.
How do I calculate whether an automation pays off?
Set the savings per year (frequency × minutes saved × hourly rate) against setup costs, running costs and the risk of unnoticed errors. Include the time for exceptions that are still handled manually, because the exception rate often decides whether the calculation works.
Why do automation projects fail?
Often because of gaps in the documentation: exceptions nobody described end up in the error folder, detours get automated along with everything else, and the knowledge of how the automation works sits with a single person. Capturing the as-is process fully beforehand and documenting the automation afterwards prevents this.
Does the works council have to be involved in process automation?
In Germany, the works council must be informed about and consulted on the planning of work procedures and workflows including the use of AI (section 90 BetrVG). If a system is objectively capable of monitoring employees' performance or behavior, codetermination under section 87(1) no. 6 BetrVG applies. Involve the works council before rollout and clarify details with legal advisers where needed.
Sources
- German Works Constitution Act (BetrVG), section 90(1) no. 3 and (2) - information and consultation on work procedures and workflows including the use of artificial intelligence; section 87(1) no. 6 - codetermination on technical systems
- General Data Protection Regulation (GDPR), Article 22 - automated individual decision-making
- ISO 9001:2015, clause 4.4 (Quality management system and its processes) and clause 7.5 (Documented information)