What Does It Cost to Automate Business Processes
How to work out the cost of your own case, what makes a project expensive, and the warning signs in a quote. No price tables that age.
1. Why nobody quotes you a price on the phone
You ask what automating a process costs and the answer is always "it depends". That is irritating, but true — and the reason is concrete. The same request — "automate invoicing" — can mean copying data between two applications that already have APIs, or extracting values from PDFs arriving by email in twenty different layouts. The first is hours. The second is weeks, and may not be worth doing at all. What sets the price is not the name of the process. It is how many systems it touches, whether those systems have APIs, how many exceptions the rule has, and what happens when it fails. This article gives you no figure, because any figure I wrote would be wrong for your case. It gives you the **method to work out yours**, and the signs that separate a serious quote from a careless one.
2. Price the problem first, not the solution
Most companies ask for quotes without knowing what the current process costs them. Then they cannot judge whether the proposal is expensive. Measure before you ask. For two weeks, record: **How often the process happens**, per day or week. Count, do not estimate — almost everyone gets this wrong, usually low. **How long each occurrence takes**, start to finish, interruptions included. Time a few and take the average. **Who does it**, and what an hour of that person costs the company — gross salary plus employer costs, divided by working hours in the month. **How often it goes wrong**, and what each error costs: the wrong invoice that has to be corrected, the customer who never got a reply, the order that shipped late. You end with an annual figure. That is the ceiling on what makes sense to invest, and the basis of any conversation about return.
# Custo anual do processo manual, com os seus números.
vezes_por_semana = 40 # contadas, não estimadas
minutos_por_vez = 12
custo_hora_empresa = 22.00 # bruto + encargos / horas úteis
erros_por_mes = 3
custo_medio_erro = 35.00
horas_ano = vezes_por_semana * 52 * minutos_por_vez / 60
custo_mao = horas_ano * custo_hora_empresa
custo_erro = erros_por_mes * 12 * custo_medio_erro
print(f"horas por ano : {horas_ano:,.0f}")
print(f"custo de mão de obra: {custo_mao:,.0f} EUR")
print(f"custo dos erros : {custo_erro:,.0f} EUR")
print(f"CUSTO ANUAL : {custo_mao + custo_erro:,.0f} EUR")3. The three parts of any quote
An honest quote separates three things, and anyone bundling them into one number is hiding one of them. **Build.** The work of designing, connecting systems, testing and going live. It is one-off, and it is the part everyone sees. **Tooling.** Subscriptions for the platforms used, and hosting if any. It is monthly, and it compounds: an automation that is cheap to build can be expensive across five years of subscriptions. **Maintenance.** APIs change, systems update, business rules evolve. A flow without maintenance degrades — not suddenly, but quietly. Anyone telling you there is no maintenance cost either does not know or is not telling you. Always ask for all three separately. And ask explicitly: *what happens when this stops working in eight months, and what does that cost?*
4. What makes an automation project expensive
The table below is what, in practice, separates a job of hours from a job of weeks.
| Factor | Cheap | Expensive |
|---|---|---|
| Data source | API documentada | PDFs, emails, capturas de ecrã |
| Number of systems | Dois | Quatro ou mais, um deles antigo |
| Exceptions to the rule | Processo uniforme | "Depende do cliente" |
| Human judgement | Nenhuma | Aprovações a meio do fluxo |
| Failure tolerance | Pode repetir-se | Dinheiro ou prazos legais |
| Process maturity | Escrito e estável | Na cabeça de uma pessoa |
| Volume | Constante | Picos sazonais extremos |
5. What gets paid, and why I am not giving you a number
You will find articles with price tables by type of automation. Be sceptical of them. The figures depend on the country, on the kind of supplier — freelancer, agency, large consultancy — on the real complexity, and on the year they were written. A table published two years ago no longer describes the market, and one written for the United States does not describe Iberia. What helps is **comparing proposals**, not comparing against a table. Get three quotes from the same written brief. If they come back very different, the difference is not the price — it is what each one understood you were asking for. That tells you the brief was unclear, and it is worth finding out now. And always work out the **return**, not the absolute price. A job costing twice as much that pays back in four months beats a cheap one that pays back in two years.
6. How to write the brief so quotes are comparable
Half of all absurd quotes come from vague requests. Write these six things and you get proposals you can compare. **The process, step by step**, as it happens today. Including the step that "is just copying into a spreadsheet". **The systems involved**, by name and version. If any is bespoke or old, say so — it changes everything. **The volume**: how many times a day, and whether there are peaks. **The exceptions**: the cases where the process is different. These are what set the price, and there are always more than anyone remembers first time. **What happens when it fails**: does anyone notice? How long can it be down? **Who manages it afterwards**: you, someone internal, or you want it to stay with the supplier. Ask for the quote to separate build, tooling and maintenance. Anyone refusing to separate them is hiding one of the three.
7. Warning signs in a quote
**A fixed price with no questions.** Anyone quoting automation without asking about exceptions either did not understand the problem or will ask for more money halfway. **Savings percentages promised upfront.** "We cut costs by 40%" without having seen your numbers is marketing. The saving depends on your process, and nobody can promise it before measuring. **No mention of maintenance.** No automation exists that does not need it. **Everything lands in a closed platform** without them saying so. Ask what happens if you want to change supplier: can you take the flows, or do you start over? **They do not discuss failure.** Ask what happens when the API on the other side is down. If the answer is vague, the system will fail silently. **A deadline that is too short.** Automating well requires understanding the process, and understanding the process takes time.
8. When automating is not worth it
I say this knowing I work in this field, and precisely because of that. **When the process happens rarely.** Twice a month justifies building nothing. The development time never comes back. **When the process is about to change.** Automating something that changes in three months is building to throw away. Wait for it to settle. **When nobody can explain the process.** If each person does it their own way, the problem is not missing automation — it is a missing process. Automating first only makes the mess faster. **When the saving is time nobody will reuse.** Saving two hours a week for someone who has nothing else to fill them with generates no value. A saving only counts if that time goes somewhere useful. **When a simple change fixes it.** Sometimes the manual step exists because someone misconfigured a tool three years ago. Worth looking at that before building on top.
9. Where to start if you have never automated anything
Do not start with the most expensive process. Start with the most **boring and predictable** one. Look for one that happens every day, always follows the same steps, touches two applications with APIs, and where a failure breaks nothing serious. Copying form entries into a sheet, sending a confirmation email, creating a record in a CRM. It pays off for two reasons. It is quick, so you see a result before the enthusiasm wears off. And it teaches you to think in flows — the second automation comes out considerably better than the first, whoever builds it. Only then go after the expensive process. By that point you know which questions to ask and you understand what you are buying.
Frequently Asked Questions
How long before automation pays for itself?
Divide the total first-year cost — build plus tooling plus maintenance — by the annual saving you worked out in section 2. The result is years to payback. Under a year is good; over three, question whether it is worth doing.
Is a no-code tool cheaper?
To build, almost always. Over time it depends on the billing model: tools charging per operation get expensive with volume. And there is the cost of being tied to the platform, which you only feel when you want to leave.
Can I automate without a developer?
Simple flows between applications with ready integrations, yes. Once exceptions, messy data or several systems appear, the curve rises fast. The sign you need help is when you spend more time working around the tool than solving the problem.
What if the company that built it disappears?
Which is why it matters where the work lives. Ask for account access in your own name, and documentation of what each flow does. If it all sits in the supplier’s account with no documentation, you did not buy an automation — you rented one.
Does AI make this cheaper?
It makes it possible to automate things that previously were not — reading free text, classifying requests, extracting data from unstructured documents. It does not make rule-based automation cheaper, and it adds a per-use cost and a margin of error that did not exist. Use it where rules run out.