Here is the direct answer on how to choose automation software: define the specific problem first, map the workflow it needs to handle, then test a real process through the trial before you sign anything. In that order. Every time. The rest of this post is the detail behind why that order matters and what to look for at each step.
I have been doing automation implementations since 2018. In 100+ projects, the companies that chose the wrong tool almost always made the same mistake: they picked based on the demo, not based on their actual process. The tool looked great. The salesperson was enthusiastic. The slide deck had very professional arrows. Three months later, they were paying for software their team had quietly stopped using.
TL;DR
Write down the specific problem before you look at any tools. Ask five questions: does it solve the actual problem, does it connect to your existing systems, can your team use it without a PhD, what does it cost at real volume, and what happens when it breaks. Then test with real data before you commit. And if your process is still a mess, no software will fix that — see the process mapping guide first.
The demo trap (and why it costs you months)
Every automation platform has a demo that looks excellent. The data is clean. The workflow is simple and well-chosen. The presenter knows every keyboard shortcut. It is genuinely impressive, and it is designed to be — the sales team has run that demo a thousand times and they know exactly which features make people say yes.
The problem is that none of that maps to your messy, real-world process with its exception cases, its approval chains, and the three people who each do the same step slightly differently. When you get the keys and try to build your actual workflow, you discover the gap between "works in a demo" and "works for us."
The pattern I keep seeing in 100+ projects: companies buy the tool that impressed them in February, spend April and May trying to make it fit, and by June they are calling me to help them either fix it or replace it. (Both of those calls are more expensive than the right conversation in January. I mention this every time. It does not always land.)
Start with the problem, not the product
Before you look at a single tool, write one sentence: "We spend X hours per week doing Y manually, which causes Z." Fill in the blanks honestly. If you cannot fill in the blanks, you are not ready to buy software yet.
"We need automation" is not a problem statement. "Our finance team spends 12 hours a week manually entering invoice data from email attachments into our ERP, and errors cause payment delays on about 8% of invoices" — that is a problem statement. It tells you what to automate, what success looks like, and how to measure whether the tool is working.
If you have not mapped the workflow yet, do that before anything else. The process mapping guide covers how to do it in an afternoon. You cannot evaluate whether software fits a process you have not documented.
The five questions that actually matter
Once you have the problem defined, run every candidate tool through these five questions. Not the marketing checklist. These five.
Does it actually solve the specific problem?
Not "does it do automation generally" — does it handle your exact workflow. The trigger you need. The systems it has to talk to. The exception cases your process actually has. Build a rough version in the trial. If you cannot get it to 80% without calling support, that is your answer.
Does it connect to the systems you already use?
Make a list of every system the workflow touches. Your ERP, your email, your CRM, your storage. Check the integrations list — not the marketing page, the actual connectors. If your ERP is not there natively, ask how people have solved that. "Via API" is a real answer, but it adds implementation cost and complexity. Factor that in.
Can the people using it actually use it?
Hand it to the person who will manage it day-to-day — not your most technical person, the person who will actually own it. Can they read what it is doing. Can they fix it when something breaks without calling a developer. If the answer is no, you have bought yourself a dependency. That dependency will cost you every time the workflow needs adjusting.
What does it cost at real volume?
Free tiers and starter plans are designed to get you in. Check the pricing at the volume you will actually hit in 12 months. Some platforms charge per task, some per user, some per workflow. Run the numbers at 2x your current volume. If the cost jumps sharply, factor that into the decision now, not when the invoice arrives.
What happens when it breaks?
Every automation breaks eventually. A system it talks to changes its API. A data format shifts. Someone adds an exception the workflow does not handle. Ask: who gets notified when it fails, how quickly, and what the fallback is. A tool with no alerting on failure is not automation — it is a silent liability.
What complexity level do you actually need?
The automation software market will happily sell you an enterprise platform for a problem that Zapier or Make.com would handle perfectly on a free tier. I reckon that Airtable plus Make.com plus basic conditional logic can solve around 70% of what most small and mid-market businesses think needs custom development. That is not a sales pitch for those tools — it is an honest observation from watching what actually gets used in the wild.
A rough guide to complexity tiers:
- Simple integration (data moves from A to B on a trigger, no decisions): Zapier or Make.com free tier, under €50/month at low volume
- Multi-step with logic (conditional branches, data transformation, multiple systems): Make.com paid or equivalent, €20–200/month depending on volume
- Document processing with AI extraction (invoices, contracts, forms): specialist tools or Make.com plus an AI step, typically €200–500/month plus setup
- ERP-connected workflows with approvals and audit trail: custom implementation required, €5,000–€15,000 to build and configure correctly
If your problem sits in tier one or two, start there. You can always upgrade. You cannot easily downgrade after six months of building on an enterprise platform.
When not to buy automation software
Nine times out of ten, when a business owner tells me they need automation software, the first question I ask is how much time the manual process actually takes. If the honest answer is under two hours a week, my advice is usually: do not buy anything yet.
The overhead of implementing, maintaining, and occasionally fixing automation — even simple automation — is real. For a two-hour-a-week manual process, the break-even on a €5,000 implementation is over a year if you are saving 1.5 hours a week. That maths only works if the person doing it costs more than most people assume, and if the automation runs without maintenance. Both of those assumptions are optimistic.
Skip software entirely if the manual process takes under two hours a week, the process changes frequently enough that maintaining automation would eat the time savings, or if the real problem is unclear ownership rather than volume. Fix the ownership first. Automation cannot compensate for a process where nobody agrees on who does what.
Also worth reading before you commit: the full guide on automating invoice processing walks through the decision framework for one of the most common automation use cases in detail, including when the numbers do and do not work.
Red flags in the demo and sales process
A few things that should make you slow down, regardless of how good the demo looked.
They cannot show you a live example with your data during the trial period. Any vendor worth working with will let you test with real examples. If the trial is read-only or heavily restricted, that is worth asking about directly.
Pricing requires a sales call to discuss. Transparent pricing is a proxy for transparent vendors. If you cannot find real numbers on the website, the real numbers are probably designed to be explained away in a conversation. (My own approach: flat fees, in writing, before any work starts. It keeps everyone honest, including me.)
The implementation timeline sounds very short. Complex automation done properly takes 2–4 weeks for a scoped project. If someone is promising full ERP integration in three days, they are either underselling the complexity or they have not asked enough questions about your process yet. Neither is a good sign.
They recommend features you did not ask about. Every feature you do not need is something that can break, something to learn, and something on your invoice. A good implementation partner recommends what solves your actual problem. If the proposal keeps expanding, ask why.
How to test before you commit
Every platform worth considering has a free trial. Use it properly — which means not building a demo workflow, building your actual workflow with your actual data.
Take 10 real examples of the process. Run them through. Check what happens with the normal case, an exception, and a failure. Does the normal case work cleanly. Does the exception get flagged or silently swallowed. When a step fails, does someone get notified or does it just stop.
Then hand it to the person who will own it. Not you. Them. Ask them to read the workflow and explain what it does. Ask them to trigger it manually. Ask them what they would do if it stopped working on a Friday afternoon. If they cannot answer that last one with confidence, the tool is too complex for the context — or it needs better documentation before it goes live. Both are fixable. Find out before you have signed 12 months.
Also on the blog
Frequently asked questions
What is the difference between Zapier and Make.com?
Both connect apps and automate workflows between them. Zapier is simpler to get started with — good for straightforward if-this-then-that logic. Make.com handles more complex multi-step flows with better data transformation. For most small business automation, either works. For anything involving conditional logic, data parsing, or multiple branches, Make.com gives you more room. I use Make.com on my own projects.
Do I need automation software or will a spreadsheet do?
Honest answer: try the spreadsheet first. If you are handling under 50 transactions a week and the manual work takes under two hours, the ROI on automation software is thin. The rule of thumb I use: when manual processing starts taking more than half a day per week, or when errors become regular, that is when automation pays for itself. Until then, a well-structured spreadsheet with a clear owner is often the right answer.
How much does automation software actually cost?
Software licences range from free tiers (Zapier, Make.com) up to €500–2,000 per month for mid-market platforms. Implementation — building and configuring the actual workflows — typically runs €5,000–€15,000 for a scoped project. The software is usually the smaller cost. The thinking, testing, and setup is where the budget goes. Any quote that skips implementation costs is not showing you the full picture.
What should I test before committing to a platform?
Run a real workflow — not a demo one. Take an actual process your team handles today, build it in the trial environment, and run 10 real examples through it. Check: does it handle exceptions cleanly, does it fail gracefully when data is missing, and can someone other than the person who built it understand what is happening. If all three are yes, you have found something worth committing to.
How do I avoid being locked into one vendor?
Keep your data and your logic separate. Your data should live somewhere you own — a database, a spreadsheet, your ERP. The automation tool should be reading from and writing to that, not holding the data itself. If you switch platforms, you move the logic. You do not lose the history. This is the single most important architectural decision most small businesses get wrong.
Are AI-powered automation tools worth the extra cost?
For document processing — extracting data from invoices, categorising incoming emails, summarising reports — yes, often. For simple rule-based automation (if order placed, send confirmation email), no, the AI layer adds cost and complexity without meaningful benefit. The test: if a human would need to read and interpret something to do the task, AI helps. If the task is just moving data from A to B on a trigger, use standard automation and save the budget.
How do I know if I have chosen the wrong automation software?
Three signals: your team has stopped using it and gone back to manual workarounds, the configuration keeps breaking and nobody is sure why, or the tool does not connect to a system you added six months ago and there is no fix coming. If any of these are true, the cost of switching is almost certainly lower than the cost of staying. Sunk cost is not a reason to keep bad tooling.
When should I hire a consultant instead of choosing the software myself?
When your process crosses more than two departments, when data security or compliance is involved, or when you have already tried one tool and it did not work. A consultant should save you more than they cost — if the engagement does not have a clear ROI attached to it, it is the wrong engagement. My first conversation is free; if you need more than that I will tell you honestly before we start.
Tijdo Koster
Automation consultant since 2009. 100–200 projects. Still answers his own emails.
If you have read this and realised you were about to choose software before writing down the problem, good. That is the right moment to stop. Write the problem down first, then look at tools. My wife has started asking "did you write the problem down first?" before I explain any new project to her. It is very annoying and completely correct.
More on the blog if you want to keep reading. The products page has the opinionated shortlist of which tools are actually worth it — which is the part most software guides skip.