Process automation in a company usually begins with a question about AI. This piece is for someone who has a process eating a few hours a week and wonders whether it really needs AI at all. It makes one claim: most requests for “automation” are settled below the AI level — by something the company is already licensed for, or by an ordinary rule. AI is the last rung of that ladder, not the first. Facts about what particular systems do come from their vendors’ own documentation and product material, checked on 8 September 2026; there are no productivity percentages here, no “hours saved” and no price brackets, because there is no source for them that could be checked.
Process automation — what it is
What is process automation? It is software carrying out the repeatable steps of a process without a person involved in every single run. A process is an ordered sequence of actions from an event — an order arrived, a deadline passed, somebody filed a request — to a result: a document in a system, a reply sent, a line recorded. Automation takes over the actions that can be described unambiguously and leaves the rest to a person.
What process automation comes down to in practice is settled by three questions: what triggers the process, what form the input arrives in, and who decides when the input is unusual. Automating office work usually founders on the third — that is our observation from projects, not a research finding. Which is why two processes that look identical from the outside can need completely different solutions: one has three input variants, the other thirty.
What process automation is not
Three terms are used interchangeably with automation, and each means something else.
Industrial robotisation concerns machines, not office software. An industrial robot has a standardised definition — an automatically controlled, reprogrammable, multipurpose manipulator, programmable in three or more axes — in the wording the International Federation of Robotics gives when it quotes ISO 8373 (read 8 September 2026; we do not quote the standard itself, because it sits behind a paywall). It shares one word with office process automation and nothing else.
Process digitisation turns a document or an action into data — and that is all. Mind the vocabulary: Polish has two words for this, digitalizacja and cyfryzacja, and some Polish vendors use the first for scanning and the second for systemic change, while others do exactly the reverse. That comes from reading their pages, not from a standard; nobody will settle the argument for you and it does not matter for the decision. What matters is one question: after the change, is somebody still doing that action by hand?
Digitising the document flow moves what used to circulate in folders into a system. A structured e-invoice is a good example: the document arrives machine-readable and lands in the system by itself, but the decision about which cost centre and project it belongs to still sits with a person. That is our reasoning, not a quotation — the medium changed from paper to a message, the decision did not change hands.
Types of automation: four levels, not four tools
Types of automation are usually listed by product name. A more useful split is by where each one stops.
| Level | What it does | What you pay with | Where it stops |
|---|---|---|---|
| 1. A feature in the system you already have | Runs scheduled and triggered actions inside one program | A subscription you usually already pay for; sometimes a paid module | At that program’s boundary, and on an unusual input |
| 2. A rule and a workflow | Joins several systems into one rules-based flow | The tool’s subscription, and sometimes the person who maintains the flow | When the input stops being structured |
| 3. Screen robot (RPA) | Clicks in the interface of an application that has no API | The robot’s licence, plus fixing it after every screen change | In the week the application changes its appearance |
| 4. AI model | Reads unstructured data and prepares a decision for approval | A charge that scales with the number and length of model calls, plus reviewing the output | At certainty — the result stops being repeatable |
The order is not accidental, although not every step of it rests on a citation. That the third level is expensive to maintain comes from the RPA vendor itself; that the fourth stops being repeatable, from the model provider itself. Both statements are below. The difference between the first and the second is our own reasoning: a thing maintained by someone in your company costs more than a thing maintained by its vendor. So the question is not “AI or not”, but “which level does this process stop at”.
The rungs stack rather than replace one another — that is our reasoning, not a citation. A model that reads an e-mail still needs level 1 or level 2 to write the result into the ERP, and where the target application has no API, level 3 does that writing. The ladder says where a process stops, not which single product to buy.
Level 1: the automation you already own and already pay for
The cheapest process automation in your company has already been bought and is most likely switched off. We said as much in one line in the n8n guide — here are the named features. This level needs no tool selection and no implementation project; it needs somebody to open the documentation of a system the company already pays for. What follows comes from vendors’ own material and names systems common in the Polish market we work in. It is not a market survey — only proof that the category exists.
ERP and document flow
Comarch ERP Optima has an automatic-operations service — Serwis Operacji Automatycznych in the Polish interface: recurring invoicing and recurring orders, reminders, sending invoices to customers and to the accounting office, synchronisations. The vendor draws the boundary immediately — it is “a Windows operating-system service that has to be configured on one computer” (Comarch ERP Optima knowledge base, updated 2 September 2024, translated from the Polish). “You already have it” means here “it is included in your licence”, not “it works”.
The most interesting feature is the one that automates nothing itself and merely points at what could be automated. Optima suggests “which documents issued manually in the program could be generated automatically using the recurring-invoice feature”, and the check “is run once a day, at the first login to a given database” (Recurring invoice proposals, updated 15 January 2025, translated from the Polish). The scope is narrow — sales invoices, not a whole process — but it is the ERP, not you, going through the list once a day.
enova365 has a Workflow module: a system that “will itself carry out repetitive actions, e.g. send reminders, fetch exchange rates, generate reports”, with processes modelled in a BPMN editor (module page, translated from the Polish). That is a product page rather than documentation, and it carries no price; whether the module is in your licence is a question for your implementation partner.
InsERT nexo has an Automation module that fires an action whenever a document is created. The vendor states that a user “can, for example, arrange for an action to follow every trade document, quotation, contract or service order that is created — for an e-mail or an SMS message to be sent”, and that “a connected InsERT Account is required to activate the Automation module” (InsERT technical help, last modified 10 July 2026, translated from the Polish). Those are the vendor’s examples, not a closed list — the page does not give the module’s full set of actions. Nor does it settle whether the module costs extra; check the vendor’s price list.
The mailbox
Rules in Outlook act on incoming mail automatically, without asking. The same help page carries the cheapest possible lesson about the limits of level one: in classic Outlook, a client-side rule with a custom action “runs only on the computer where it is installed and only when Outlook is running” (Microsoft Support, read 8 September 2026). Automation that requires somebody’s laptop to be switched on is conditional automation.
CRM
In CRMs the same category is called workflow and is wired into the pricing tier. HubSpot makes workflows available on the Professional and Enterprise plans (HubSpot knowledge base). Pipedrive describes automation as a pair — a trigger event and an action — available “on Growth and higher plans” (Pipedrive knowledge base, updated 3 September 2026). Those are two instances of one category, not a CRM comparison — plan names change often enough that only the vendor’s price page on the day you look is reliable.
Before you buy anything, work through this list for one process. It extends the principle on the AI automation page: do not build what you can buy on a subscription. We go one step further — often you do not need to buy at all, only to switch something on.
- Search your ERP’s documentation index for the words automatic, recurring, schedule, workflow — or, in a Polish-language system, automat, cykliczny, harmonogram, workflow.
- Check whether the system points at automatable work by itself, without being asked.
- Establish whether the automation module is in the licence or costs extra — and whether anyone ever configured it. A service bought and never switched on looks exactly like a working one on the contract.
- Review the rules in the shared mailbox and check whether any of them runs on one computer only.
- Compare the upgrade to a higher CRM tier against the cost of a separate tool.
- Only now write down what none of the points above covers. That, and only that, is the scope of level 2.
Level 2: a rule and a workflow
The second level begins where one program ends. A workflow tool — n8n, Make, Power Automate, Zapier — does not change the kind of decision that can be automated. It changes the reach: an event in one system triggers an action in another, and between them sit conditions, transformations and an approval step. Some of these tools are already paid for: the free Power Automate licence covers — for work or school accounts in a Microsoft Entra tenant — cloud flows, but only on standard connectors and without sharing flows (Microsoft Learn, document dated 20 July 2026). The rest of the price is two items, the second of which is routinely left out: the tool’s subscription, and the person who builds the flow and then keeps fixing it after every change in the connected systems.
This level has one hard condition: the input must be structured, and the rule must be one somebody can write down. If both hold and the process still fits in one spreadsheet kept by one person, the honest answer is sometimes to leave that spreadsheet alone.
Level 3: the screen robot (RPA) — automation versus robotisation, and when it breaks
The screen robot exists because the second level has nothing to take hold of. Microsoft defines it plainly in the Power Automate licensing documentation: RPA “is needed to interact with applications, which are lacking a prebuilt connector and which don’t have APIs that could be used to build a custom connector”, and you automate those applications “by teaching Power Automate for Desktop to mimic the mouse movements and keyboard entries of a human user, as if a robot was using the computer” (Microsoft Learn, document dated 20 July 2026). Note who is saying it: the vendor selling the robot puts the robot behind the API. The same page places running desktop flows locally, with a person at the keyboard, inside the free licence — on standard connectors and without flow sharing. This is also where automation and robotisation part company, because the Polish word robotyzacja does two jobs at once: an arm on a shop floor, and a program clicking in somebody else’s window. The terminology of that second family is set out in IEEE 2755-2017, published on 28 September 2017, status: active — a guide that exists, as it says itself, because “there are no common definitions of concepts, capabilities, terms, technology, types, etc.” Like ISO 8373, the standard itself sits behind a paywall, so we do not quote it.
Why it breaks is stated in the RPA vendor’s own documentation. UiPath rates the maintenance of classic selectors as high and their tolerance of interface change as low, and lists what breaks them: “minor UI layout or theme updates”, “dynamic element IDs”, “label or class name changes” (UiPath Docs, read 8 September 2026; the page also advertises a replacement product, which does not make the list any less accurate). A robot that stops finding its targets because somebody changed a colour theme is a maintenance liability, not a saving.
Level 4: AI — what it adds to a process and what it takes from certainty
The fourth level comes in where there are too many input variants to write rules for. Neither the test that settles this nor the place where the human stays is a discovery of this article — we set out both earlier on the service page, in the sections on how AI automation differs from ordinary automation, and where the human stands in the process. A rule is reliable for exactly as long as the input looks the way whoever wrote it assumed.
What that means in practice: the model decides by similarity, and the price paid for that is not monetary — the model provider names it outright. OpenAI writes in its API documentation that Chat Completions responses are non-deterministic by default, so the results of the same request can differ between calls (OpenAI documentation, read 8 September 2026). This is not about accuracy or making things up, only about repeatability. What else changes on the bill at that point is in the piece on what an AI implementation costs.
As it happens, the law draws that boundary too. The EU regulation on artificial intelligence states in recital 12 that the notion of an AI system “should not cover systems that are based on the rules defined solely by natural persons to automatically execute operations” (Regulation (EU) 2024/1689 on EUR-Lex — quoted from the text as published on 12 July 2024; the regulation was subsequently amended by Regulation (EU) 2026/1744, read 8 September 2026). The European Commission issued non-binding guidelines on applying that definition on 6 February 2025. For an engineer that is a useful line: a rules workflow and a screen robot are not AI systems. Whether a particular system in your company is one is your lawyer’s call, not this article’s and not your supplier’s.
What happens when the input does not fit: three scenarios
The same exception produces three different results at different levels, and only the first is visible straight away.
Stopping, and the consistent mistake. Either the rule does not find what it is looking for and the process halts, or it finds it in the wrong place and copies it without hesitation, the same way every time. Stopping is the better outcome because it is loud: somebody sees the queue growing that same day. The mistake surfaces at month-end close, or on the customer’s side. We described both scenarios earlier on the service page, and both belong to levels one to three.
The probable answer. The third result appears only with a model, which neither stops nor errs consistently: it proposes an answer, and on a repeat of the same input it may propose a slightly different one. It is neither correct nor incorrect in the sense a rule is; it is probable. That changes the kind of control needed. At levels one to three you check whether the rule is complete; at the fourth, what share of proposals a person corrects and whether that share is rising. Without that second control nobody will notice a deterioration, so the implementation is not ready to run.
One order through four levels: where each of them stops
One order stops at a different point on each level: level 1 at the first non-standard order, level 2 at the body of an e-mail, level 3 at a change to the portal’s layout, and level 4 at certainty. A distributor takes orders by three routes: some customers type them into the body of an e-mail, some send a PDF order form, and the largest raise a line in their own supplier portal.
A composite of several projects; the figures are illustrative and do not come from a measurement at a single client.
Level 1. A mailbox rule routes portal notifications into a separate folder, and the ERP raises a document from a template for the handful of customers who always order the same items. It stops at the first order that is not standard — which is to say, at most of them.
Level 2. A workflow pulls the structured export from the portal and creates the order in the ERP with nothing re-keyed by hand. There is no per-call model charge here and no screen that could change. It stops the moment the input is the body of an e-mail: there is no field to take the item code and quantity from.
Level 3. The portal offers neither an export nor an API, so a screen robot logs in and re-keys the lines into the ERP the way a person would. It stops in the week the portal changes its screen layout — usually quietly, without raising an alert.
Level 4. A model reads the e-mail body and the PDF form, proposes order lines with item codes and quantities, and a salesperson approves them before the level-2 flow writes them into the ERP. It stops at certainty: the proposal is sometimes incomplete, so the approval step is not decoration but a condition of going live. We described that process, with its measurable effect, as the first of our AI automation examples.
Before deciding which level your process is on, fill in five rows for yourself. Without them, a conversation with any supplier will be a conversation about a tool rather than about a process.
| Question | Your number |
|---|---|
| How many items a month? | |
| How many arrive through a structured channel (portal, XML, form)? | |
| How many need re-keying from one screen into another system? | |
| How many a month fit no rule at all? | |
| Who settles those exceptions today? |
The fourth row decides the fourth level. If it comes out at zero, a model has nothing to do here — and if nobody can give you the number, that is the first task, not an implementation.
When a process needs none of these levels
Sometimes the honest answer is “do not automate this”, and it is better heard before the quotation than after it. The conditions for a good candidate and the data-readiness test are set out in the section on which processes qualify for automation — we are not repeating them here. One thing does need adding, and it follows from the ladder itself: a feature you already pay for beats a build at the second level even when the volume would justify the build. That is the point at which we lose work ourselves — and we say so plainly; the full list of things we do not do is on the what we don’t do page.
What next
The order matters more than the choice of tool: first check what you have already bought, then whether a rule is enough, then whether a screen robot is needed, and only at the end whether the process really requires a model. In practice that is one afternoon with your own ERP’s documentation and the exception table from the previous section filled in. Once you know which level the process is on, what remains is the order of implementation: the seven steps from choosing a process to maintaining it are in how to implement AI in a company, and if the word agent comes up along the way, in how an AI agent differs from a chatbot. The way we run such a project from diagnosis to handover is on the AI automation page. Start with one process, and with that one number from the fourth row.