Tijdo Koster
Automation16 min read

Business process automation:
what it costs and how to start

"Business process automation" is the IT department's way of saying "stop making someone re-enter the same data into three different systems every morning." Perfectly useful concept. Wildly inconsistent execution. Here is what to actually do.

Team collaborating in an office — business process automation starts with understanding the workflow first

Photo: Pexels

Here is the direct answer: business process automation is the use of software to handle repeatable, rule-based tasks — invoice approvals, onboarding checklists, data entry between systems, scheduled reporting. Any task where the same inputs produce the same outputs, every time, without anyone needing to think about it. That is the territory.

What it is not: a fix for a broken process, a replacement for judgment, or something that works before anyone has mapped what the process actually is. Get those three caveats wrong and you will automate your chaos into a faster, harder-to-untangle version of itself. I have watched this happen in roughly 40% of the initial conversations I have with new clients. The number is not improving.

TL;DR

Business process automation works best on high-frequency, rule-based tasks — anything where you could write the steps on a napkin without footnotes. Document the process first, pick the simplest tool that solves it, start with one workflow. A well-scoped project takes 2–4 weeks and €5,000–€15,000. A poorly scoped one takes six months and costs everyone involved considerably more than the software.

Person reviewing a workflow on a laptop before setting up automation

Photo: Pexels

What business process automation actually is

"Business process automation" covers everything from a simple Zapier trigger to a full AI-powered document workflow with multi-system integration. That range is where the confusion lives. Most people who enquire about it are sitting somewhere in the middle — and most consultants they speak to will helpfully quote them the top end.

For the purposes of this post, I am talking about what works for SMEs and mid-market companies in the real world: workflow automation, system integrations, document handling, and rule-based routing. Not robotics. Not hyperautomation. Not a 12-month enterprise rollout. The kind of thing that, when scoped properly, goes live in 2–4 weeks and pays for itself before year end.

A quick distinction worth making, because it comes up constantly:

  • BPA (Business Process Automation) — the broad approach. Any software-driven method for handling a repeatable business workflow.
  • RPA (Robotic Process Automation) — a specific technique within BPA, where software mimics user actions on an interface. Useful when there is no API. More fragile than a proper integration.
  • BPM (Business Process Management) — the discipline of documenting, analysing, and improving processes before deciding which ones to automate. The step most companies skip. Also the most important one.

(BPM is also the step that consulting firms bill the most hours on and deliver the least visible output for. I mention this because it is true, and because I am a consultant, and the irony is not lost on me.)

Nine times out of ten, teams come to me saying "we need automation" when what they actually need is to stop manually copying data between a spreadsheet, a CRM, and an ERP. The fix is a clean integration, not an enterprise automation platform. Start with the smallest version of the solution that actually solves the problem.

The processes worth automating first

Not every process is worth automating. Some are too judgment-dependent. Some happen so rarely that the setup cost exceeds the saving by a wide margin. The ones that pay off fast share three traits: high frequency, clear rules, low need for human judgment.

The practical test: can you describe the task as "whenever X happens, do Y, then Z, then notify W" — without footnotes? If yes, it is a candidate. If the honest description includes phrases like "it depends," "you need to read the situation," or "ask the person who's been here longest" — it is not ready. Document and standardise it first, then come back.

The categories that almost always qualify:

  • Data entry and transfers — anything manually copied from one system into another on a schedule
  • Approval workflows — expense reports, invoice sign-offs, document reviews where the steps are the same every time
  • Onboarding and offboarding — new employee setup, access provisioning, welcome communications
  • Reporting and data aggregation — pulling numbers from multiple sources into a weekly or monthly summary
  • Customer communications — acknowledgement emails, status updates, appointment confirmations triggered by system events

The categories that almost never qualify straight away: anything involving a customer complaint that needs a real judgment call, anything where the exception rate is high enough that the automation spends more time escalating than processing, and anything with compliance implications you have not fully mapped. Automate those last, after the easier ones are running and you have built some confidence in the system.

Business team reviewing workflow documentation together

Photo: Pexels

Five real business process automation examples

Concrete examples do more work than definitions. Here are five that appear in most mid-market implementations, along with what "automated" actually means in practice for each one.

Invoice processing

Email arrives with a PDF invoice → system extracts supplier name, amount, and reference → routes to the relevant approver based on value threshold → once approved, posts to the ERP and archives the document. Before: a finance employee opens, reads, types, routes, and chases every single one. After: the same employee reviews exceptions and handles anything the system cannot categorise. Volume capacity roughly doubles without adding headcount. I covered the specifics in more detail in the invoice automation post.

Employee onboarding

New hire contract signed → system triggers IT access provisioning, sends welcome documentation, schedules first-week calendar blocks, notifies payroll, creates accounts in relevant systems. Before: HR manually works through a checklist and chases each department individually. After: the checklist runs itself. A human is still involved — for the edge cases, which do exist, and which is why you still want someone checking the exception queue.

Expense approval workflows

Expense submitted → categorised automatically → routed to line manager if under policy threshold, finance team if over → approved or queried → payment processed and logged. The more interesting version connects this to your GL coding rules, which stops the manual re-entry at the other end entirely.

Scheduled financial reporting

Pull data from ERP on a schedule → format according to a defined template → distribute to stakeholders by email. This sounds simple because it is. It also replaces 4–8 hours of manual pulling, formatting, and checking every week for most finance teams. Genuinely one of the fastest-ROI automations available and consistently underestimated.

Customer support routing

Inbound enquiry received → classified by category and urgency using basic rules or AI classification → routed to the right team member → customer receives an automated acknowledgement with expected response time. This is not a replacement for the human who actually answers. It is a way to make sure the right human answers faster, without a colleague manually forwarding emails at 8am.

Notice what these five share: a clear trigger, a defined set of steps, and a human who reviews exceptions rather than processing every instance manually. That is the pattern. If your version does not have all three of those elements, the scope is not ready yet.

What it costs and how long it takes — honest numbers

I will give you the range I actually work in, because vague pricing is one of the things that makes this industry harder to navigate than it needs to be.

For a scoped automation project at an SME or mid-market company: €5,000–€15,000 depending on complexity. Single-process builds with straightforward integrations sit at the lower end. Multi-system workflows with document handling, approval logic, and ERP integration sit at the higher end. Most projects I implement fall somewhere in the middle.

Timeline: 2–4 weeks from kickoff to live. That assumes the process is documented, the data is clean, and the people involved understand what is changing and why. Add time for each of those that are missing — and one of them usually is.

Tool subscriptions add ongoing cost on top. Zapier and Make.com run from free to €100–€300/month depending on volume and plan. Power Automate is included in most Microsoft 365 subscriptions. ERP-native automation modules are priced per module. Budget €50–€300/month for tooling on a typical SME setup. That number does not move much unless your transaction volume scales significantly.

Here is the opinion I will state plainly: if a project costs more than €5,000 and you cannot point to a specific ROI target — hours saved per week, invoices processed per month, headcount growth avoided — pause it.That is not pessimism. That is how you avoid building technology for technology's sake. McKinsey's research on automation and the future of work puts typical operational cost reductions from BPA at 20–30%. In 100+ projects, I reckon that is roughly right for companies that scope properly — and roughly irrelevant for companies that do not.

Team working through an implementation plan step by step

Photo: Pexels

The five steps that actually work

In 100+ projects since 2018, the ones that land cleanly follow roughly this sequence. The ones that run for six months and end with a partial rollout almost always missed step one.

Document the current process first

Before any tool selection, map what you actually do right now — not the version you wish you had. The version your team runs today, including the workarounds and the exceptions. If this sounds tedious, it is. It is also the step that prevents you from automating the wrong thing. I covered the how-to in more detail in the process mapping post.

Identify the single biggest friction point

You are not automating everything on day one. Pick the one step that costs the most time, produces the most errors, or creates the most downstream problems. Start there. One workflow done well teaches you more about how automation fits your operation than three half-finished ones running in parallel.

Pick the simplest tool that solves it

The right automation tool is the one that integrates with your existing stack, costs within your budget, and can be maintained by someone who is not a developer. Do not overbuy. I wrote a separate post on choosing automation software if you want a framework for this decision — five questions that cut through the vendor noise.

Build small, test in parallel, then switch

Run the automation alongside the manual process for at least a week before turning the manual version off. This is not lack of confidence in the build — it is how you find the exceptions you forgot to document in step one. Every process has them. You want to find them in testing. (Also: the average mid-market approval workflow has approximately eleven undocumented exceptions. The number eleven is not a joke.)

Assign a human to own the output

Automation that nobody checks is a liability. Designate someone to review the exception queue, catch errors, and escalate if something breaks. Not as a permanent full-time job — as a two-minute daily check while you build confidence in the system. This is non-negotiable. I have said it in roughly 80 of 100+ project kickoffs. I will keep saying it.

When to do it yourself — and when to hire someone

Here is where I will be honest about my own lane — because telling you when not to hire a consultant is, I reckon, more useful than the standard version of this section.

Try it yourself first if:the automation involves one or two tools that connect cleanly, the rules are simple, there are no compliance or data privacy implications, and the failure mode if something breaks is "a workflow stops and someone notices." Zapier, Make.com, and Power Automate are genuinely accessible for non-technical users. A well-structured Airtable workspace with basic automation rules handles a surprising amount of what small teams think requires a custom build. Spend a weekend on it. You will either solve the problem or learn enough to scope a proper project. (You might be surprised. Or you might send me an email on Monday. Either outcome is fine.)

Honestly, for most simple workflow pain, a basic tool setup clears about half the jobs I get called to fix. Save yourself the consultant fee until you actually need one.

Hire someone when:you are dealing with ERP integrations, invoice processing at volume, multi-system data flows with reconciliation logic, or anything where a misconfiguration causes a real compliance or financial problem. The failure mode of a badly implemented finance automation is not "a workflow breaks." It is "you have been double-posting invoices for three months and the audit finds it." That is worth paying to get right.

The pattern I keep seeing: companies DIY the small stuff, hit a wall when the complexity jumps, and bring in help with a partially-built system that needs reworking before it can be extended. Not a disaster — but cleaner to scope properly from the start when you know the volume will be significant.

If you want a framework for evaluating tools when you do need one, the automation software guide covers the five questions that actually matter — and what to ignore in the vendor demo.

Empty conference room — a meeting that did not go as planned

Photo: Pexels

The mistake that kills most automation projects

I want to tell you about a project I walked away from empty-handed, because it is the best illustration I have of the thing that derails automation more reliably than any technical problem.

A construction company brought me in to implement new financial software. I showed up ready. Walked through the system. Demonstrated the workflows. Explained the integration with their existing stack.

Nothing. No buy-in. No questions. No next steps. I drove home empty-handed.

The problem was not the software. It was not the demo. It was that the finance team had no idea this was happening. Nobody told them why the company was changing systems, what the goal was, or why their input mattered. They were not part of the decision. So when I showed up with "here is your new workflow," they had no reason to be on board. Entirely reasonable position, in retrospect.

I told the manager straight: "Take time to inform your team about what the company wants to achieve and why. Get them on board before I come back."

Two weeks later: new plan, full team alignment, implementation ran smoothly.

The lesson — and I see this go wrong in roughly one in three projects — is that change management is not optional. It is the foundation. Prosci's research on change management effectiveness consistently identifies employee awareness and buy-in as the top predictor of whether an implementation lands. You can have the best automation software available, but if the people who use it every day do not understand why it is changing or what they are supposed to do with the exceptions, you have built something nobody will maintain properly.

The technical side of a business process automation project is usually the straightforward part. The part where it fails is almost always human: incomplete process documentation, no owner assigned to the output, or a team handed a new system without context. Fix those before the first line of automation logic gets written.

If AI agents are part of your automation thinking — for routing, classification, or decision support — the same principle applies. They need a defined scope and a human who owns the output. The AI agents guide covers what they actually are and the four places they genuinely earn their keep, if that direction is relevant to you.

There is more on the blog if you want to keep going. The posts on automation ROI and process mapping pick up where this one leaves off.

Frequently asked questions

What is business process automation?

Business process automation is the use of software to handle repeatable, rule-based tasks — invoice approvals, onboarding checklists, data entry between systems, scheduled reporting. Any task where the same inputs reliably produce the same outputs, and a person is only in the loop because nobody built the shortcut yet. It is not a fix for broken processes, not a replacement for judgment, and not something that works without first understanding what the process actually is.

How much does business process automation cost?

For a scoped, properly implemented project at an SME or mid-market company, the range I work in is €5,000–€15,000 depending on complexity. Simple single-process builds sit at the lower end. Multi-system integrations with document handling and approval workflows sit at the higher end. Subscription tools add €50–€300/month on top. If someone quotes you a wide "starting at" range without scoping the work first, treat that as a yellow flag.

How long does it take to automate a business process?

A well-scoped project takes 2–4 weeks from kickoff to live. That assumes the process has been documented, the tools are chosen, and the people involved understand why the change is happening. If any of those three are missing, add time — usually a lot of it. The projects I have seen stretch to six months were almost always missing the first step: nobody had actually mapped the process before trying to automate it.

What processes should I automate first?

Start with the highest-frequency, most rule-based task in your operation. Ask: can this be described as "whenever X happens, do Y, then Z" — without footnotes? If yes, it is a candidate. Invoice processing, new employee onboarding, expense approvals, and scheduled reporting are the four categories that deliver the fastest ROI in most mid-market operations. Leave anything requiring real judgment or physical presence until the low-hanging fruit is running cleanly.

What is the difference between BPA and RPA?

Business process automation is the broad category — any software-driven approach to handling a repeatable business workflow. Robotic Process Automation (RPA) is a specific technique within BPA that mimics user actions on existing software interfaces, useful when no API is available. Think of BPA as the strategy and RPA as one tool within it. Most SMEs do not need RPA; they need cleaner integrations and workflow tools, which are simpler and cheaper to maintain.

Should I automate my business processes myself or hire a consultant?

If the automation involves one or two tools, follows simple rules, and has no compliance implications — try it yourself first. Zapier, Make.com, and Power Automate are genuinely accessible for non-technical users. Hire someone when you are dealing with ERP integrations, invoice processing at volume, data privacy requirements, or anything where a misconfiguration would cause a real business problem. The failure mode of DIY is usually a broken workflow. The failure mode of a badly implemented compliance process is considerably worse.

When should I not automate a business process?

When the process is not documented, when it relies on judgment that changes case by case, or when the people involved do not understand why the change is happening. Automating a process nobody has agreed on is one of the fastest ways to make a problem harder to fix. Rule of thumb: if you cannot describe the process in a one-page flowchart without needing three footnotes explaining exceptions, it is not ready to automate.

What tools do small businesses use for business process automation?

For most small businesses the practical options are Zapier or Make.com for connecting apps and triggering workflows, Power Automate if you are already in a Microsoft 365 environment, and ERP-native automation for finance-specific workflows. Airtable handles a surprising amount of structured workflow and approval logic without any code. The right tool is usually the one that works with the systems you already have rather than replacing them.

TK

Tijdo Koster

Automation consultant since 2009. 100–200 projects. Still answers his own emails.

If you made it to the bottom and your main takeaway is that "business process automation" is just a 24-letter phrase for "do fewer things by hand," that is exactly right. The concept is not complicated. The execution is where it gets interesting, and occasionally humbling.

There is more on the blog if you want to keep reading. If you want the practical tool guide for when you are ready to build the stack, the products page has it.