What does process automation cost? Four things set the price, and none of them is the technology

Ask three vendors what a process automation costs and you will get the same non-answer three times. It depends. That is true, and it is still a dodge. The other common assumption is that the price follows the technology, meaning the model and the platform. Of everything in the project, that is the part that varies least.

The money goes somewhere else, into four things you can check before you sign anything, without reading a line of code.

Why process automation cost is hard to quote in the first meeting

Quoting a price means predicting how much work a process will be when you have only heard it described. Two workflows that sound identical in a meeting can differ by a factor of five once someone opens the systems. A vendor who answers with a number in the first call is either guessing or has already priced in the buffer.

How easily the systems open up

Getting data in and out of the systems costs more than the logic in between.

A system with a documented API, a test account and a named contact at the vendor is connected in a few days. A system that only hands over a file export at night costs several times that for the same business outcome, because now someone has to watch for the file, spot a truncated export, prevent the same records from being processed twice and handle the night the export simply does not appear.

So before you take a quote seriously, find out whether each system has an API, whether a test account exists and who in your company holds the credentials. Without a test account every project runs long, because nobody is allowed to experiment on the live system.

How many exceptions the process has

The happy path takes a day or two. The exceptions are the project.

Say a distributor wants to take customer orders out of email automatically. The happy path is an order with part numbers and quantities. Next to it sit orders with no part numbers, orders with a requested delivery date buried in a sentence, repeat orders that say "same as last time", orders going to a different address and orders that are really complaints. Each of those is a business decision somebody has to make and write down.

A quote that never mentions the exceptions has priced the happy path. That is the usual reason a cheap quote ends up more expensive than an expensive one.

You can build this list yourself before you talk to anyone. Take a hundred recent cases and sort them by how many went through untouched and what the odd ones were. Nothing else you bring to a vendor meeting is worth as much.

Who decides when a question comes up

Every project throws up questions only your company can answer. Does an order without a customer number get rejected or parked for review? Does an order above the credit limit stop or go through?

If one person is allowed to answer that within a few days, the schedule holds. If every question travels through three departments, the timeline doubles, and on a time and materials contract the cost doubles with it.

This is where you have the most influence on the price, and it costs you nothing except a decision made before the project starts.

What is allowed to go wrong

An automation that writes an internal note can be wrong now and then. One that issues invoices, places purchase orders or touches patient data cannot.

The difference is not in the business logic but in everything built around it. Restart after a failure, protection against processing the same record twice, an audit trail somebody can read, a human approval at the points that matter, and an alert that reaches the responsible team rather than a shared inbox. This part can double the effort, and it is the last place to economize.

Tell the vendor what the worst plausible failure would be. That is what determines how much safety net you need to pay for.

What the numbers roughly look like

The ranges below are rough estimates and only mean anything together with the four points above.

A single well defined process across one or two systems with decent APIs and few exceptions usually lands in the low four figures. Once it spans several systems, validates master data and handles the odd cases properly, expect the mid to upper four figures. As soon as an agent makes its own decisions, several departments are involved, or a legacy system without an API is in the chain, you are into five figures.

Anyone who quotes a number without knowing your systems and your exceptions is quoting what a different company paid.

Why a fixed price needs a defined scope

A fixed price means the vendor carries the estimating risk. That is the right way round, because the vendor can judge the effort better than you can. It only works if what gets built is written down beforehand, down to the level of the exceptions.

Without that document one of two things happens. Either the vendor adds a buffer you pay for whether or not it is needed, or the vendor prices it tight and everything not explicitly named turns into a change request later. Neither side is acting in bad faith. The scope is simply missing.

That is why an analysis comes before a fixed price. It is what makes the price hold.

What keeps costing money after go-live

The project price is not the whole price. Running costs remain and belong in the quote: platform licenses, per-request charges if a language model is involved, servers if you host it yourself, and changes when a connected system updates or a form changes shape.

The difference between buying and subscribing sits elsewhere. With a subscription you keep paying for something that rarely changes after rollout, and access ends when you stop paying. That does not make subscriptions the wrong choice, they just have to add up over the term. Model both routes across three years, running costs included, and compare then.

How to spot a quote that only moves the price around

Time and materials with no cap and no agreed checkpoints should make you nervous. So should a low entry price attached to a monthly fee that outgrows it several times over the contract term. The third warning sign is a statement of work that describes the process in a headline instead of listing which cases are covered and which are not.

The opposite signal is a good one. A vendor who asks uncomfortable questions about your exceptions before naming a price is calculating rather than guessing.

Write this down before you request a quote

Do not lead with the price question. Put four things on paper first: which process you want automated, which systems are involved and whether they have APIs, which exceptions actually occurred in your last hundred cases, and who is allowed to settle business questions. With that single sheet you get comparable quotes instead of ballpark figures, and a fixed price becomes possible at all.

Sophera Consulting works in that order. Look at the process, write down the exceptions and the interfaces, then name a fixed price, with no subscription and with handover and documentation included. The free automation check is where that starts.