Business process automation — examples and where to start

Business process automation sounds like a large IT project, and in practice it is something far more modest: moving one repeatable decision from a person to a rule. "When an enquiry comes in through the form, save it in the CRM and confirm to the customer that it arrived." "When the transfer arrives, mark the invoice as paid." Every one of these decisions used to be made by hand — provided somebody remembered.

That is why the question is not "should we automate", but "which decision do we hand to a rule, and which do we leave to a person". The answer to the second half matters more than it seems. Below we show it on our own example: the whole funnel from the form on this site to the report in Google Ads runs for us without manual work — with exceptions we left in on purpose. On top of that: Eurostat data on where European companies stand, e-invoicing as automation that arrives by law, examples by department, criteria for choosing the first process, and a calculation of when it pays back.

What business process automation is — and what RPA is

Three different things are sold today under the name "process automation". It is worth separating them, because each solves a different problem and each costs something different.

Integration through an API. Two systems talk to each other directly: the form saves the contact in the CRM, the shop passes the order to the warehouse system, the bank sends the payment notification to the accounting software. Nobody clicks anything. This is the most stable form of automation, but it requires both systems to have an application programming interface (API) — in other words, to make their data available to other programs.

RPA — robotic process automation. To the question "what is RPA", IBM gives the shortest answer: it is software that performs repetitive office tasks of human workers — extracting data, filling in forms, moving files — using scripts that emulate what a person does, and working according to rules. The US government guide digital.gov describes RPA as technology for automating "repetitive, rules-based tasks" and compares it to an Excel macro, except one that works across many programs at once. The most important sentence in IBM's description: RPA bots can be deployed where there is no API, or no resources for a deep integration. The robot clicks on the screen because there is no other door.

AI automation. IBM puts the difference in one sentence: RPA is process-driven, while AI is data-driven. An RPA bot follows only the process a person has defined, whereas an AI model recognises patterns in data, including unstructured data, and learns over time. In practice, AI automation starts where the rule cannot be written down directly: someone has to read an email and work out what the customer wants, summarise a conversation or assign a ticket to a category.

In a real company these three layers often work together in one process. Take a supplier's invoice as a PDF: an AI model reads the number, the amount and the due date, a rule checks whether they match the order, and an integration writes the result into the accounting software. A person only gets the documents where something did not match. Each layer does what it is best at, and none has to pretend to be the others.

This split leads to the first decision to make before anyone starts choosing a tool: does the system the data has to come from, and go to, have an API? If it does — integration. If it does not, and the process is a rule — RPA. If the rule cannot be written down — AI, ideally with a person who approves the result.

Process automation in European companies — where things stand

The most sobering figures come from Eurostat's survey of how EU enterprises use digital technology, which covers companies with at least ten employees and self-employed persons. Its 2025 results on business software were extracted in May 2026.

A CRM system — the place where contacts with customers are recorded — is used by 28.51% of enterprises overall, but only 24.69% of small ones (10–49 people). Among medium-sized enterprises the figure is 43.77%, among large ones 65.43%. ERP is used by 46.45% of enterprises overall — 41.08% of small ones, 69.93% of medium-sized and 88.71% of large ones. Business intelligence (BI) tools are used by 16.28% of enterprises overall and 11.45% of small ones.

The technologies most often associated with automation are used by fewer companies still. According to Eurostat's figures on artificial intelligence, 19.95% of EU enterprises used AI in 2025 — up from 13.48% a year earlier — with 17.00% of small, 30.36% of medium-sized and 55.03% of large enterprises. AI technologies for automating different workflows or assisting in decision-making — the category that includes AI-based robotic process automation — were used by 5.35% of enterprises overall, 4.13% of small ones, 8.67% of medium-sized and 24.42% of large ones. That category counts only AI-based automation; plain integrations and rule-based bots are not in it, so the real share of automated processes is higher. But the order of magnitude is the same.

These numbers point to something more important than a ranking. Three small companies in four have no CRM at all — no system automation could write anything into. Contacts sit in the mailbox, orders in a spreadsheet, notes on the salesperson's phone. A robot that moves data from an email to the CRM has nowhere to move it. That is why automation in a small company starts with data gathered in one place, not with a robot — and that is good news, because the first step is usually the cheapest.

In medium-sized companies the problem looks different. There the systems usually exist already — seven in ten have ERP, more than four in ten have CRM — they just do not talk to each other. Sales work in one program, accounting in a second, the warehouse in a third, and between them sits a person who retypes. In a company like that, business process automation most often means integration: not a new system, but a connection between the ones already paid for.

E-invoicing — automation that arrives by law

There is one process in which European companies are losing the choice of whether to digitise it: the invoice. E-invoicing turns it from a document someone reads and retypes into a structured file that a program can read without a person involved.

The EU has set the direction in its VAT in the Digital Age package (ViDA, Directive (EU) 2025/516):

• since 14 April 2025, member states have been able to introduce mandatory e-invoicing at home, under the conditions the package sets out,
• from 1 July 2030, cross-border B2B sales within the EU move to digital reporting built on the e-invoice,
• by 1 January 2035, countries that already run their own real-time reporting systems have to align them with the EU model.

What this means for your company in the next few years depends on where it is registered: some member states already require businesses to issue or receive e-invoices, others have set dates, others have not yet decided. Check your own country's timetable — and the countries of your main customers and suppliers.

For automation, the receiving side matters most. Wherever your suppliers send structured e-invoices — because the law requires it or because they choose to — your purchase invoices arrive in a format with fixed fields and an identifier that pins each one down, instead of as PDFs laid out in a hundred different ways.

That makes the purchase invoice the first process in many companies that can be connected without retyping and without a robot clicking on the screen. The accounting software or the sales system takes in the e-invoices, matches them with orders or transfers, and a person deals only with those that do not match. Nobody has to read a PDF or guess where the VAT number sits on the page. If you are looking for a first process to automate and your invoicing software already handles e-invoices, half the work may be behind you.

Before you build anything around e-invoicing, check three things in your software. First, whether it only sends invoices or also takes in the ones addressed to you — they are two separate functions. Second, who in the company has access to the channel or the portal through which e-invoices arrive, and what happens when that person is on holiday. Third, where the invoice goes once it has been received: does someone still have to assign it to an order by hand, or does the software do it on its own from the number and the amount? Real automation only begins at that last step.

Business process automation at our place — from the form to Google Ads

The most honest way to show what this looks like is on a system we know from the inside: this site. Every step below runs without manual work.

The form and the spam filter. When someone sends an enquiry, the system scores it in several ways: whether a hidden field that a person cannot see has been filled in, how long it took to fill in the form, and whether the content looks like a sales pitch aimed at us. An important detail: the filter flags, but rejects nothing. Every submission is saved and sent by email, and the filter's score travels with it. Thresholds and phrases are set in the admin panel, without changing code.

The CRM record. The submission immediately becomes a contact in our CRM. The same contact collects everything that person has done: the form, a calculator result, a quiz, a booked meeting, a project brief. We recognise the contact by email address, and the first and last source of the visit — which ad or campaign it came from — is recorded automatically. The phone number is always stored in the same international format. That is not pedantry: Google matches the hashed number, so the same phone written once with spaces and once without is, to Google, two different people.

The meeting in the calendar. The booking module reads free slots from Google Calendar, writes the event there, and the meeting lands in the CRM next to the rest of the contact's history. Every 15 minutes the system checks who is due a reminder — a day and an hour before the call — and on the same schedule checks that the connection to the calendar still works.

Conversions in Google Ads. Google Ads fetches a conversions file from our address on its own, according to an import schedule. Leads with a click identifier go in directly; the others are matched on hashed email address and phone number. So the advertising also learns from contacts that came in by phone. Submissions the filter flagged as spam, and contacts disqualified in the CRM, are held back before sending — we come back to that in the section on what breaks.

Email and content. The mailbox synchronises with the CRM every 10 minutes. Publishing an article triggers translation into the other languages, a short link, the choice of a sharing image, a refresh of the page and notification of the address to search engines. The system checks for scheduled publications every 5 minutes.

What we deliberately do not automate

The most interesting thing about this funnel is a rule it does not contain. A contact moves through stages: new lead, qualified, client, repeat client, and also rejected or junk. Only one stage changes automatically: a client with a second project becomes a repeat client. It is the only change that can be safely derived from the data alone.

All the others need human judgement — no rule can read whether a conversation really turned into a project. Negative stages are never overwritten by the automation. Even project dates are entered by hand, because a contract is often closed with a date earlier than the day it is recorded.

That does not mean human judgement stays in a drawer. When someone marks a lead as junk, the automation retracts its conversion in Google Ads, and a qualified lead is given a higher value. A person judges; the automation carries the judgement onwards. That, in our view, is the healthiest division of labour in any automation.

Business process automation — practical examples in a small company

The examples below are grouped by department. Each can be described with the same sentence: when X happens, do Y and record the result in Z. If you cannot name Z in your company, start with that.

Sales automation usually starts with the simplest row in the table — an enquiry that does not get lost in the inbox. The salesperson sees the contact with its whole history before calling back, and within a minute the customer knows the message arrived. The second step is reminders: a quote without a reply does not have to wait until someone happens to remember it.

Customer service automation in a small company rarely means a chatbot. More often it is about the customer not having to phone to ask "what's happening with my order" — because they get the status before they think of asking. AI starts to make sense here only for assigning tickets to categories or drafting replies that a person approves.

In the team, time and absence recording comes up most often. When staff work in the field, the natural place for such a request is the phone — when that needs an app of its own and when an off-the-shelf one will do, we cover in the article on mobile apps for businesses.

In finance, the biggest gain comes from combining two rows of the table: the e-invoice received and the bank transfer. When the software matches one with the other on its own, the person handling receivables deals only with exceptions — an underpayment, a missing number, a transfer without a reference — and the reminder about an overdue payment goes out before anyone has a chance to forget it.

In marketing, automation most often keeps things regular: the request for a review goes out after every completed job, not when someone remembers. It is exactly tasks like these — small, repetitive and easy to skip — that are the first to disappear when a company gets busy.

What is deliberately missing from the table: percentages of savings "from implementations". Every company has a different volume and a different cost of an error, so a figure from someone else's project tells you nothing. How to calculate your own is in the last section.

Where to start with process automation, and with what

The old rule still works best: start with what is simple and annoying, not with what is biggest. A good first process meets four conditions:

• it is repetitive — it happens every day or every week, not once a quarter,
• the rule can be written in one sentence — "when X, do Y"; if describing it needs "it depends", it is not a rule yet,
• the data is already digital — in a system, a form or an e-invoice, not on a sheet of paper or in an employee's memory,
• the cost of an error is known and bearable — a reminder sent by mistake is a trifle, a wrongly booked payment is not.

One test helps weed out processes that only look ready: for two weeks, do them by hand but following a written list of steps. If the list survives two weeks without corrections, the rule exists and can be handed to automation. If someone adds an exception every other day, the process needs putting in order first — automation would set every one of those exceptions in stone.

Once the process is chosen, three roads remain.

No-code workflow automation tools: Zapier, Make, n8n. They connect ready-made services without programming and are usually enough for the first automations. They differ in how they charge, which matters more than the starting price as volume grows. Zapier counts tasks, that is, every action performed. Make counts credits — most actions cost one credit. n8n counts executions of the whole workflow, regardless of the number of steps, and has a version you can host yourself. In companies that work on Microsoft 365, Power Automate plays a similar role. The same process can therefore cost very different amounts depending on how many steps it has.

Integration inside your own system. When the logic is unusual, the data is sensitive or the automation has to combine several systems into one picture — like our CRM with Google Ads — it makes more sense to write it inside a system you already have or are building. When that pays off, and when an off-the-shelf tool is enough, we cover in the article custom software or off-the-shelf. If that system is going to be an application in the browser, our guide to web applications covers the basics.

RPA, when there is no API. An old warehouse program, a trading partner's portal with no interface for other programs, a system nobody develops any more. Here a robot clicking on the screen is sometimes the only way. Just remember that since it imitates a person in the interface, a change in how that interface looks can stop it.

What breaks when automation works

Automation does not remove errors. It repeats them faster and more consistently than a person. An employee who notices that something is wrong stops after the second time. A rule makes the same mistake on every record it can reach. That is why automating a process that does not work in the first place only speeds up the chaos.

We have a fresh example from our own backyard. On 21 September 2026 a one-off script was tidying up the related articles shown under texts on this site. It saved its changes without any information about publication status — and the system took that as saving a draft. Seven published articles turned into drafts and for about five minutes showed a "not found" message instead of their content. We restored them and checked them on all three domains. We wrote the lesson down as a rule: every ad hoc write to a published text must carry its publication status. Our standard publishing tool does exactly that. A script written in a hurry did not.

The second example is less spectacular, but more costly, because it lasted longer. The spam filter and the manual disqualification of leads in the CRM existed for a long time before they changed anything outside the database. All that time, the conversions file for Google Ads reported spam as full-value conversions, and the bidding system learned to look for more clicks like those. Every element worked correctly. The error sat in the connection between them — where nobody was looking.

The third source of trouble lies outside your company: a change on the other end of the connection. Access to an account expires, a provider changes its interface, someone disconnects the app in the settings. The automation will not report it on its own unless someone taught it to.

From that incident and from everyday work come three things every automation should have from day one:

• an owner — a named person who knows the automation exists, what it does and whom to tell when it stops,
• a check after writing — confirming that the effect is as intended, especially with changes to many records at once,
• a trail — an automation that silently rejects things leaves a problem nobody will notice. That is why our spam filter flags submissions instead of deleting them, and a separate job checks every 15 minutes whether the calendar connection still works and, when access expires, sends an email asking for it to be reconnected. Automation that watches over automation is not overkill; it's what lets you stop thinking about it.

What automation costs and when it pays back

The calculation is simple, and it is worth doing yourselves before anyone presents you with an offer. On one side: how many hours a month the process takes today, multiplied by the full cost of an hour of that person's work. On the other: the cost of implementation and the monthly cost of maintenance — the tool's subscription, fixes when the system on the other side changes, the time of the person who watches over the automation. Automation pays back after as many months as you get by dividing the implementation cost by the difference between the monthly saving and the maintenance. If maintenance eats the saving, the automation never pays back, however modern it looks.

Count the hours honestly, with the whole process, not only the data entry itself. The time a process takes also includes looking for missing information, asking the customer again, correcting mistakes and checking whether someone has already replied. The easiest way is to measure it for a week or two, noting every time someone picks up the task.

Two things do not fit into that formula and often outweigh it: the cost of the error the automation will not make, and the response time for the customer. Value them separately and cautiously.

With us, implementing automation is priced after a review of your processes, in which we calculate the payback on your hours rather than on examples — so the quote reflects the number of systems involved and whether they have an API. What [process automation for companies](pages:6a01c1f053d7a1c9c21df4f7) involves with us, and which systems we connect to, is described on the service page.