Business process automation: what to automate, what it costs, what quietly fails

Most of what gets called automation is digitisation

Business process automation is one phrase covering five different things, and the distance between them is most of your budget. A useful definition is narrow: a process is automated when it starts on its own, ends in a defined outcome, and the rules that cover the cases in between are written down somewhere other than a person's head. Everything short of that is preparation for automation, which is worth doing and should be priced as what it is.

The clearest example is the one companies are proudest of. Replacing a paper form with a web form is digitisation. It removes typing, storage and a certain amount of squinting, and it removes exactly zero decisions. Whoever used to read that form still reads it, and the hours the process eats are almost entirely in the reading. Poland is about to get a large involuntary demonstration of this, because KSeF turns supplier invoices into structured XML whether you were ready or not, and finance teams are discovering that structured data on its own does not code an invoice.

The ladder below is the one we use when someone asks what level a process needs. Read it as a cost ladder rather than a maturity model. Nobody gets points for reaching the top, and the right answer is the lowest level that actually removes the work.

The jump that costs the most is 2 to 3, because that is where you stop being able to predict the output and start having to check it. Of the seven production systems we run, six sit at level 2 or 3 and exactly one is a real agent, which is a count we did honestly rather than aspirationally. If your shortlist is all level 4, the shortlist is wrong before the budget is.

Worth knowing where the market is: Eurostat put AI use across EU enterprises at 19.95% in 2025, with Poland at 8.36% and only Romania lower (retrieved 4 August 2026). Four out of five European companies are still somewhere between level 0 and level 2, which is a better place to be than it sounds.

The process that annoys you most is rarely the one that pays

Ask a team which process to automate first and you get the one people hate. Annoyance is a poor signal, because it tracks how unpleasant a task feels rather than how much it costs. The arithmetic is not hard and almost nobody runs it, which is why the honest first step is a week of counting rather than a workshop.

For each candidate, write down three numbers: how many times a month it runs, how many minutes one run takes end to end, and what has to be true for a machine to do it. Multiply the first two by twelve and you have hours a year. Multiply that by a loaded hourly cost and you have the money on the table. Then apply the discount nobody applies: an automation never takes 100% of a process, and 70% is a realistic planning figure once you account for setup, review and the cases that fall out.

Here is that count for an invented 30-person distributor, with the assumptions on the table: minutes are measured, not estimated, and the loaded cost of an office hour is set at €25 as a placeholder. Put your own number in, because this one changes the ranking.

The monthly report is the one everybody nominates, because a whole day disappears into it and everyone can feel that. It is last on the list. Twelve runs a year means twelve chances for a build to pay itself back, and the rules for assembling a report change more often than that.

Now the number that settles it. Invoice coding releases 320 hours a year, and at 70% capture that is 224 hours, or about €5,600. A build has to come in well under that to be interesting, and the published bands for anything with a model in it do not. Azilen prices a simple rule-based chatbot at $10,000 to $50,000 and a RAG knowledge agent at $80,000 to $180,000 and up (retrieved 4 August 2026). Against €5,600 a year, an $80,000 build never pays back, and no amount of enthusiasm fixes that.

Two things change the answer, and only two. Volume is the first: the same €5,600 becomes €56,000 at ten times the invoice count, and the build cost barely moves, because the build cost tracks process complexity rather than repetitions. The second is dropping a level. The same 320 hours attacked at level 1 or 2, with a scheduled job, a mapping table and a fallout queue, is a build measured in days and a licence measured in tens of euros. That is the boring answer, and for most companies under fifty people it is also the correct one.

Business process automation sends three bills, the quote shows one

The tools are cheap and everybody knows it, which is exactly why the licence gets used as a proxy for the cost of the project. n8n's entry cloud plan is €20 a month for 2,500 workflow executions, Pro is €50 for 10,000, and Zapier's Professional tier is $19.99 a month billed annually for 750 tasks (both retrieved 4 August 2026). At level 1 and level 2 that licence is genuinely most of the running cost. It is also never what made a project expensive.

The second bill is the run. For a level-3 or level-4 system it has three parts: model tokens, infrastructure, and human hours spent watching quality. One agent we keep in production bills between $10 and $100 a month in tokens and infrastructure depending on load, and takes roughly ten hours a month to keep honest. The ratio matters more than either number. The infrastructure line is loose change next to the human line, and across the first year the maintenance total lands in the same order of magnitude as the build rather than as a rounding error, which is the line thin quotes leave on your side of the table.

The third bill is the one with no invoice. Somebody has to own the process after launch: read the fallout queue, notice when the volume of exceptions creeps up, and be the person an integration partner emails when a field changes. Budget it as a real fraction of a role. When that fraction is zero, the automation works until the first thing that changes, and then it stops in a way nobody notices for a fortnight.

On timelines, published estimates are consistent enough to plan against even if you distrust the source. Azilen puts simple agents at 4 to 8 weeks, mid-complexity retrieval agents at 3 to 5 months, and full multi-agent systems at 6 to 12 months. Our own experience runs to the pessimistic end of those, for a dull reason: the calendar is set by how long it takes to get access to the data, not by how long it takes to write the code.

Where a working automation quietly dies

Automations rarely fail loudly on day one. They fail in month four, and the post-mortems keep landing on the same few causes.

Start with exceptions, because that is the one you can calculate in advance and almost nobody does. Take 100 cases a week. The system handles 85 cleanly. The other 15 fall out, and a fallout case now takes about three times as long as it used to, because a person has to work out what the machine already did before they can finish it. Your baseline was 100 units of work. You are now spending 45. That is a 55% saving against the 85% the business case promised, and the difference between those two numbers is what later gets called a failed project. Fifty-five percent is a good outcome. The problem is that nobody wrote it down in advance, so it reads as a shortfall.

Second, and this is the one that kills systems rather than disappointing them: ownerless data. Every automation reads something it did not create. A supplier list, a price table, or the mapping that decides which region a customer belongs to and that nobody has opened in two years. Ask who owns that table and the honest answer in most companies is that it was correct on the day it was imported. Models make this worse, because they are fluent about stale inputs. Grounding an assistant in a 500K-record base taught us to validate every numerical claim against its retrieved source before the answer ships, for the plain reason that a drop rate quoted from memory is confidently, precisely wrong. Your version of that is a discount that was superseded in March.

Third, the process nobody wrote down. Automating a process means specifying it, and specification is where projects actually stall. We hit the pure form of this building a design-to-code system: a Figma file looks like a specification and is really a set of visual hints that leave the important rules implicit, so a model fills the gaps by guessing and produces plausible output that fails review. A pricing process held in one person's head behaves identically. If nobody can write the rules on one page, the first deliverable is that page, and it is worth paying for on its own.

Fourth, and simplest, is that the automation talks to customers and nobody told compliance. Since 2 August 2026 the EU AI Act's transparency obligations apply, and a bot that a person could mistake for a human has to say what it is. That is a line of copy and a logging decision if you handle it during the build, and a retrofit if you do not, which we walk through in what the AI Act actually changes for a system already in production.

A checklist you can run this week

None of this needs a vendor. It needs a week and somebody willing to count.

1. Count, do not estimate. Pick the three loudest candidate processes and have whoever runs them log every occurrence for five working days: timestamp, minutes, and whether it was routine or odd. Estimates are wrong in both directions and the direction matters.

2. Multiply. Runs a month, times minutes, times twelve, times a loaded hourly cost. Then take 70% of it. The number you are left with is the annual budget the automation has to beat, including its run cost.

3. Write the rules on one page. If the person doing the work cannot get the decision logic onto a single page, you have found the actual first project. Do that before you shop.

4. Count the odd ones. From the five-day log, what share was not routine? Under 10% and you are in good shape. Over 25% and the case for automating this year is weak, whatever the hours say.

5. Name the data owner. For every table, list or file the process reads, write a person's name next to it. Any blank is a scheduled failure. Fill it before you build, not after.

6. Pick the lowest level that works. Walk the ladder from 0 upward and stop at the first level that removes the work. Level 3 and 4 need checking infrastructure that levels 1 and 2 do not.

7. Decide what happens when it is wrong. Who sees the error, how fast, and can the action be reversed? If a mistake is expensive to unwind, you are building an approval gate, and the gate is part of the scope from the start.

8. Set one metric and a review date. One number, measured before and after, checked at 30 and 90 days. Without a before-number there is no way to tell a working automation from a comfortable one.

If the outcome of that week is that nothing on your list clears the bar, that is a real result and it cost you a week. On which process to pick when several clear it, we wrote a longer piece on the four tests that decide whether a process deserves a machine at all.

What these levels look like when they are actually running

For calibration, here is where our own systems land on that ladder, since abstract levels are easy to nod at and hard to picture.

At the integration end, a Telegram job tracker ingests RSS feeds, deduplicates, and fans one posting out to every user whose filters match, which holds up at millions of messages a day. No model anywhere in it. The same shape as a well-built order-status notifier, and it is unglamorous on purpose.

One level up, a content pipeline takes a CSV of terms and publishes validated articles, replacing 20 to 40 minutes of writer time per article - and the interesting part is not the generation but the link checker that unwraps anything returning a 404 before it publishes. At level 3, an assistant over a 500K-record knowledge base answers with grounded citations because every number is validated against its source chunk. The single level-4 system is a voice race engineer that reads live telemetry through 19 tools and answers in under two seconds, and it is level 4 because the questions genuinely cannot be enumerated in advance. Underneath all of them is the same boring requirement that a 10,000-viewer traffic spike taught us: capacity is designed for the worst minute, not the average one.

If you run that checklist and want a second opinion on what came out of it, we do a free audit and will tell you plainly when the answer is a spreadsheet and a scheduled job rather than anything with a model in it: book one here.

FAQ