How much does business process automation cost?

Because the same request, 'automate our order process', can be a small job at one company and a large one at another, and the size of the company rarely explains the difference. The difference is almost always the three drivers below, and you can assess them for your own process before you speak to anyone.

A price for your own process has to wait for your exception count: any figure given without it would be a guess presented as data. What this page sets out is the structure of an estimate and the arithmetic behind it, and a note in the estimate section below gives our own typical range.

Exceptions are the main cost driver. Each distinct way a case can depart from the happy path needs a decision (automate it, route it to a person, or reject it visibly), a state to hold and a test, so cost follows the number of paths through the process rather than the number of steps on the main one.

The happy path is the version described in the meeting: the order arrives complete, the customer exists, the stock is there. The expensive cases are the order for a product you stopped selling, the customer spelled two ways in two systems, the supplier invoice that arrives as a photograph, the job reallocated after its clock has started. When an estimate surprises someone, it is usually because they counted the steps.

Even a case that sounds trivial needs a deliberate answer. On the fleet-telematics order system, an order sent twice had to be handled explicitly: rows are matched against existing records, so a resend corrects the existing row instead of creating a second one. Multiply that by every case like it.

• Rare and cheap to handle by hand: leave it manual at first. A case that arises only rarely seldom repays the build, and it adds a path that has to keep working.
• Frequent: usually a process problem dressed as an automation problem. Many of these disappear if the upstream form or intake is fixed.
• Rare and expensive: this is what is worth engineering, because the case that costs real money when missed is exactly the one a person misses.

What matters is how many systems believe they own the same piece of information, not how many tools are involved. Pushing data one way from the system that owns it to one that displays it is well-understood work. If two systems both hold the customer and a person can edit either, you are building a reconciliation, which costs a multiple of a sync rather than a margin on top of it.

That last row is arithmetic. Linking every system to every other needs up to n(n-1)/2 connections: 4 systems need 6, and 6 systems need 15. A hub in the middle needs n, so 4 and 6. The hub costs more to build and less to keep adding to.

The question that best predicts the effort is: what is the join key? If it is an identifier both systems store, the work is mechanical. If it is the customer name, you are also building fuzzy matching, a review queue for near misses, and a way to merge two records that turned out to be one.

When a rule needs memory, a once-only guarantee, per-user visibility or a permanent audit trail, it belongs in a database rather than in an automation platform's scenario. Platforms are good at rules of the form 'when this happens, do that', and get progressively worse beyond it. Crossing this line is usually the step change in an estimate, because the job moves from configuring a platform to building and testing a small system.

• This can only happen once. A guarantee that survives two runs firing in the same second is a unique constraint in a database, not a check step in a scenario. On Skofi Outreach, a sequence step can send only once per enrolment as a database constraint, so two schedulers firing at once cannot double-email a prospect.
• This depends on what happened before. Anything measured in business days against a real holiday calendar, anything that survives reallocation, anything comparing this month with last.
• These people may see only their own records, enforced on every read path rather than by each screen remembering to filter.
• We must be able to prove what it did, months later. That needs an append-only log with field-level history, which a platform's run log does not replace once its retention window closes.
• The rule must hold however the data is written. If an import, an automation and a person can all write the same records, the rule belongs where all three pass through.

On the order system we built for a fleet-telematics provider, the commitment was two business days. That one sentence carried a real Australian public holiday calendar, a clock that survives reallocation to another installer, escalation that fires without anyone remembering to check, and a page for installers who were never going to hold monday.com seats. That is the work of a schema and a small service, not of a platform rule.

Fill in the formula one term at a time, and ask anyone quoting you to break their figure out the same way. Every input below is something you count or something a builder quotes for your process. None of them is a benchmark, and this page deliberately offers no typical day counts.

So effort = (H + E + I + D) x (1 + t), and cost = effort x the day rate you are quoted. The useful part is how two variations of the same process compare, because they would both be described in a meeting as 'automate order intake'. Compare them symbolically. If people edit the data in both systems, the integration term gains a reconciliation component, and if a business-day clock is needed, D is no longer zero. The difference between the two is (reconciliation + D) x (1 + t), and neither term appears in a quote that only counts steps. If you fix the intake form upstream and remove k exception paths, the saving is (the sum of d(i) over the k removed paths) x (1 + t), with no extra tooling at all.

Five things lower the estimate: one person who can decide, an agreed system of record, permission to leave rare exceptions manual, history that does not have to move, and real examples of every document on day one.

• One person who can decide. The biggest multiplier on a small project is often not technical but a question that takes several meetings to answer.
• An agreed system of record. If everyone can say which system wins when two disagree, much of the integration design is already done.
• Permission to leave rare exceptions manual. Automating the bulk and making the rest visible is usually the better first release.
• History that does not have to move. Migrating and proving years of records can be larger than the automation it supports.
• Real examples of every document that arrives, creased ones included. A clean sample makes a build look cheap and then makes it late.

Running cost is metered platform usage plus the time it takes to keep the automation working. Usage you can calculate yourself; the unit price is on the vendor's current pricing page, which is why it is not quoted here.

Metered usage

Many platforms bill per operation, task or execution, so the bill follows volume and structure rather than the build. On a per-operation platform, operations a month = records per day x operations per record x days it runs in the month. Count the operations per record from the scenario's own run history, and the records per day from your own volumes. The bill scales in direct proportion to volume, so ten times the records is ten times the operations from an unchanged build. A scenario that iterates over rows can also use many more operations than one that batches the work, for identical output, so check structure before volume grows.

The second year

Budget time for upkeep. Upstream systems change their fields, credentials expire, new exceptions appear, and the person who understood the automation moves on. List each automation with its upstream systems and a named owner, and allot review time per quarter to each. A budget of zero is how an automation becomes something nobody dares touch. Any custom component also needs hosting, usually small next to the build and the people time; check your host's current pricing.